Podcast appearances and mentions of stephanie right

Joël shares his preparations for his RailsConf talk, which is D&D-themed and centered around a gnome character named Glittersense. Stephanie expresses her delight in creating pod-related puns within thoughtbot's internal team structure, like "cross-podination" for inter-pod meetings and the adorable observation that her pod resembles "three peas in a pod" when using the git co-authored-by feature. Together, Stephanie and Joël discuss bringing one's authentic self to work, balancing personal disclosure with professional boundaries, and fostering psychological safety. They highlight the value of shared interests and personal anecdotes in enhancing team cohesion, especially remotely, and stress the importance of an inclusive culture that respects individual preferences and boundaries. Transcript: We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 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, at the time of this recording, we're recording this the week before RailsConf. I've been working on some of the visuals for my RailsConf talk and leaning on AI to generate some of these. So, my talk is D&D-themed, and it's very narrative-based. We follow the adventures of this gnome named Glittersense throughout the talk as we learn about how to use Turbo to build a D&D character sheet. And so, I wanted the AI to generate images for me. And the problem I've had with a lot of AI-generated images is that you're like, okay, I need a gnome, you know, in a fight doing this, doing that. But then, like, every time, you get, like, totally different images. You're like, "Oh, I need an image where it's this," but then, like, the character is different in all the scenes, and there's no consistency. So, I've been leaning a little bit more into the memory aspect of ChatGPT, where you can sort of tell it, "Look, these are the things. Now, whenever I refer to Glittersense, whenever you draw an image, do it with these characteristics that we've established what the character looks like." Sometimes I'll have, like, a text conversation kind of, like, setting up the physical characteristics. And then, it's like, okay, now every time you draw him, draw him like this, or now every time you draw him, draw him with this particular piece of equipment that we've created. And so, leaning into that memory has allowed me to create a series of images that feel a little bit more consistent in a way that's been really interesting. STEPHANIE: Cool. Yeah, that makes sense because you are telling a story, right? And you need it to have a through line and the imagery be matching as you progress in your presentation. I actually don't know a lot about how that memory works. Does it persist across sessions? Do you have to do it all in one [laughs] go, or how does that work? JOËL: So, there's, like, a persistent chat. So, you can start sort of multiple conversations, but each conversation is its own thread with its own memory. And it will sort of keep track of certain things. And sometimes I'll even say, "Hey..." instead of, like, prompting it for something to get a response, you could prompt it to add things to its memory. So say like, "From now on, when I ask you these types of questions, I want you to respond in this way," or, "From now on, when I ask you to generate an image, I want it done in this format." So, for example, RailsConf requires all of their slides to be 16 by 9. If I want, like, a kind of cover image or, like, something full-screen, I need an image that is 16 by 9. So, one of the things I prompt the AI with is just, "From now on, whenever you generate an image, give me an image in 16:9 aspect ratio." STEPHANIE: Cool. I also was intrigued by your gnome's name, Glittersense. And I was wondering what the story behind that character is. JOËL: The story behind the name is that I was playing D&D with a friend who was this very kind of eclectic Dragonborn character. And I did some sort of valiant deed and got the name Glittersense bestowed upon me by this Dragonborn for having helped him out in some, like, cool way. So, that's a fun name. And so, when I was searching for a name for my character in this talk, I was like, you know what? Let's bring back Glittersense. I like that. I think it captures a little bit of, like, the wonder and the whimsy of a gnome. STEPHANIE: That's really cute. I like that a lot. JOËL: So, Stephanie, what's been new in your world? STEPHANIE: So, lately, I've been having a lot of fun with coming up with names of things. You know the saying how naming is one of the hardest things in software? Well, okay, I'm not actually going to talk about anything that I named very particularly well in my code, but I've been just coming up with a lot of puns. It's just, I don't know, my brain is kind of in that space. And one thing that...I can't recall if I have talked about this on the show before, but our team at thoughtbot is experimenting with kind of smaller sub-teams within it called pods. We have now kind of been split into pods with other people who are working on maybe similar client projects. I have been having some really good naming ideas around [laughs] pod-related puns. So, one thing that we did as part of this experiment was setting up meetings for pods to meet each other, and spend time together, and kind of share what each other was up to. And I was the first to coin the term cross-podination, kind of like cross-pollination. And I think I just, like, said it offhand one day, and then it caught on. And I was very pleasantly surprised to see that people just leaned into it and started naming those meetings cross-podination meetings. And then, another one that came about recently was my pod there's three of us in it, and we were pairing, or I guess it's not really called a pairing if there's three. We were mobbing or ensembling, whatever you want to call it. And sometimes we like to use the git co-authored-by feature where you can attribute, you know, commits to people that you worked on them with. And in GitHub when you, you know, add people's emails to the commit, you know, you see your little GitHub profile picture in a little circle. And when you have multiple people shared on a commit, it is just, like, squished together. And since we're a trio, I was like, "Oh, it's like we're, like, three peas in a pod." JOËL: [chuckles] STEPHANIE: And I realized that it was an excellent missed opportunity for our pod name. We're something else. But I am hereby reserving that name for the next pod that I am in. You heard it here first [laughs]. It looked exactly like just three snug little peas. And I, yeah, it was very cute. I was very delighted. And yeah, that's what's new for me. JOËL: I'll also point out the fact that you are currently talking on a podcast. STEPHANIE: Whoa, whoa. So, you and I are a pod [laughter]. We're a podcasting pod [laughs]. Wow, I didn't even think about that. My world is just pods right now [laughs], folks. JOËL: How do you feel about puns as an art form? STEPHANIE: [laughs] Wow, art form is a strong phrase to use. I don't hate them. I think it depends. Sometimes I will cringe, and other times I'm like, that's great. That's excellent. Yeah, I think it depends. But I guess, clearly, I'm in my pun era, so I've just accepted it. JOËL: Are you the kind of person who is, like, ashamed but secretly proud when you make a really good pun? STEPHANIE: Yeah, that's a very good way to describe it. I'm sure there are other people out there [laughs]. JOËL: What's interesting with puns, right? Like, some people love them, some people hate them. Some people really lean into them, like, that becomes almost, like, part of their personality. We had a former teammate who his...we made a custom Slack emoji with his face, and it was the pun emoji because he always had a good pun ready for any situation. And so, that's sort of a way that I feel like sometimes you get to bring an aspect of your personality or at least a persona to work. What parts of yourself do you like to bring to work? What parts do you like to maybe leave out? STEPHANIE: Yeah, I am really excited about this topic because I feel like it's a little bit evergreen, maybe was kind of a trendy thing to talk about in terms of team culture in the past couple of years, but this idea of bringing an authentic or whole self to work as, like, an ideal. And I don't know that I totally agree with that [laughs] because, like you said, sometimes you have a different kind of persona, or you have a kind of way that you want to present yourself at work. And that doesn't necessarily mean it's a bad thing. I personally like some kind of separation in terms of my work self and my rest of life self [laughs]. Yeah, I just think that should be fine. JOËL: So, you might secretly be the pun master, but you don't want your colleagues to know. STEPHANIE: [laughs] That's true. Or I save my puns only for work [laughter]. If I ever have, like, a shower thought where I think of a really good pun, I will, like, send a Slack message to myself to find [laughs] the perfect opportunity to use this pun in a meeting [laughs]. I don't actually do that, but that would be very funny. JOËL: I feel like there's probably a sense in which nobody is a hundred percent their authentic self or their full self in a work situation, you know, it varies by person. But I'm sure everybody, to a certain extent, has a professional persona that they inhabit during work hours. STEPHANIE: Yeah, and I like that the way we're talking about it, too, is a professional persona doesn't necessarily mean that you're just a little...matching kind of a business speak bot [laughs], where it's kind of devoid of personality, but just using all the right language in their emails [laughs] and the correct business jargon or whatever. To me, what is important is that people are able to choose how they show up or present themselves at work. That's, like, an active choice that they're making, not out of obligation or fear of consequences. You know, like, it's fine to be a little more private at work if that's just how you want to operate. And it's also fine to be more open about sharing things going on in your personal life. Because I've seen ways in which both have been more enforced or, like, there's pressure to perform one way or another. And that could mean, like, when people kind of encourage others to try to be more of themselves or, like, share more things about personal life. That's not always necessarily a good thing if it's not something that people are comfortable with. And I suspect that we have kind of pulled back a little bit from that, but there was certainly a time when that was a bit of an expectation. And I'm not sure that that was quite [chuckles] what we wanted to aim for in terms of just the modern workplace. JOËL: It is interesting because I think there can be some advantages to maybe building connection with people by sharing a little bit more about your life. But, again, if there's pressure to do it, that becomes really unwholesome. STEPHANIE: Yeah. Unwholesome is a good word to use. Like, I want that wholesome content [laughs] at work. And I actually have a couple of thoughts about how I prefer to share, like, just personal things with my team members. And I'm curious kind of where you fall on this as well. But a couple of things that our team does that I really like is we have a quarterly newsletter that one of our team leads puts together. She has an open call for submissions, and people just share any, like travel plans, any professional wins, any kind of personal life things that they want to share. People love talking about their home improvement adventures [laughs] on our team, which is really fun. And yeah, like, just share photos and a little blurb about what they've been up to. And this happens every quarter. And it's always such a delight to remember a little bit like, oh yeah, my co-workers have lives outside of work. But I really like that it's opt-in and also not that frequent, you know? It's kind of like, this is the time to share any like, special things that have happened in the past three months. And yeah, I think every time a new dispatch of it comes out, everyone kind of gets the warm and fuzzy feelings of appreciating their co-workers and what they've been up to. JOËL: Do you think that that kind of sharing sort of maybe helps personalize a little bit of our colleagues, especially because we're all remote and we're interacting with each other through a screen? STEPHANIE: Yes. Yeah. That's another good distinction. I think it is, like, a little more important that there are touch points like these when we are working remote because, yeah, the water cooler conversation just doesn't really happen nearly as much as it does when you're in an office. And I feel like that's the kind of thing that I would talk about at the water cooler [laughs]. It's like, "Oh yeah, I went to Disney World, or traveled for this conference, or I built new garden beds for my yard," just stuff like that. I don't know, I don't find that...like, when you're just communicating over Slack and email, there's not a good place for that kind of stuff. And that's why I really like the newsletter. JOËL: One thing that's interesting about the difference between in-person and remote is that, in person, a way that you can express personality in the office is you can do some things with your workspace. You might have some items on your desk that are of personal interest. And, you know, you might still do that when you're working remote, but those don't get captured by your webcam unless it's in your background. Your background you can get real creative with. But you can also, like, really curate that to, like, show practically nothing. Whereas if you were putting things on your desk in the office, there's kind of no way for your colleagues not to see that. So, you had to be...like, it had to be things that you were willing for everyone to see. But at the same time, sometimes it's nice to be able to say, hey, I'm going to put a touch of, like, things that are meaningful to me in my work life. STEPHANIE: Yeah, I really like that. I mean, Joël, your background is always these framed maps on the wall, hanging on the wall, and that is very you, I think. Did you kind of think about how they'll just be your background whenever you're in a meeting, or they just happened to be there? JOËL: So, these I had set up pre-pandemic. I like the décor. And then, when I started working from home in 2020, I was trying to figure out, like, where do I want to be to take meetings? And I was like, you know what? The math wall is pretty cool. I think that's going to be my background. I guess now it's almost become, like, a bit of a trademark. STEPHANIE: Yeah, I feel that. My trademark...I have a few because I like to move around when I take meetings. So, when I'm at my desk, it's the plants in my office. When I'm in my kitchen, it's either my jars [laughs]. So, I have, like, open shelving and just all of these jars of, you know, some of it is ingredients like nuts, and grains, and stuff like that, and some of it is just empty jars that I use for drinking water. So, I have my jar collection. And then, occasionally, if I'm sitting on the other side of the table [chuckles], all of my pots and pans are hanging in the background from above my stove. So, yeah, I'm the jars, pots, and plants person [laughs] at the company. JOËL: You know, we were talking earlier about the idea that it's harder to see your sort of workspace in a remote world. And I just remembered that we do a semi-regular...there's, like, a thread at thoughtbot where people just share pictures of their workspace, and it's opt-in. You don't have to put anything in there. But you get a little bit of, like, oh, the other side of the camera. That's pretty cool. STEPHANIE: Yeah, I love seeing those threads. And I think a lot of people in our industry are also gear nerds, so [laughter] they love to see people's, like, fancy monitor and keyboard setups, maybe some cool lighting, oh, like, wire organization [laughs]. JOËL: Cable management. STEPHANIE: Yep. Yep. Those are fun. And I actually think another one that we've lost since going remote is laptop stickers because that was such a great way for people to show some personality and things that they love, like programming stuff, maybe, like, you know, language stickers or organizations like thoughtbot stickers, too, and also, more personal stuff if they want. At a previous company, we were also remote, and someone came up with a really fun game where people anonymously submitted pictures of their laptop stickers. And we got together and tried to guess whose laptop belonged to who just based on the stickers. JOËL: Oh, that's fun. STEPHANIE: Yeah, that was really fun. I keep forgetting that I wanted to organize something like that for thoughtbot. But now I'm just thinking about it, and I feel the need to decorate my laptop with some stickers after this [laughs]. JOËL: One thing I do want to highlight, though, is the fact that several years back, when people were talking a lot about the importance of bringing your sort of authentic or whole self to work, one of the really valuable parts of that conversation was giving people the ability to do that, not forcing people to sort of hide parts of themselves, especially if they don't fit into a dominant culture or demographic, in order to be able to even function at work, right? That's a sort of key aspect of, I guess, basic inclusivity. And so, I think that's still a hundred percent true today. We want to build cultures that are inclusive, both in our in-person professional situations and for remote teams. STEPHANIE: Yeah, 100%. I think, for me, what I think is a good measure of that is, you know, how comfortable are people disagreeing at the company kind of in public or sharing an alternative perspective? Like, that should be okay and celebrated, even, and considered, you know, with equal weight as kind of what you're saying, the dominant identity or even just opinion. Like, especially in tech, I think people have very strongly held opinions, and when they're disagreed with...I've become a little skeptical of the idea of, like, this is how we do things here or, like, we don't do that. And I think that rather than sticking to a, like, stance like that, there's always room to incorporate, like, new approaches, new perspectives, new ways of thinking to a given problem. And that can only happen when people are comfortable with going there, you know, and kind of saying, like, "This is important to me," or, like, "This is how I feel about it." And that, in and of itself, is just equally valid [laughs] as whatever is taking the airtime currently. JOËL: That's really interesting because I feel like now you've leaned into almost the idea of psychological safety for a team. And if you're having to sort of repress or hide elements of the way you think, or maybe even sort of core elements of your identity to fit in with a team, that's not psychologically safe, and you can't have those deeper conversations. STEPHANIE: Yeah, 100%. I think it's two sides of the same coin, you know, it's like two ways of saying the same thing, that people should be able to conduct themselves in the way they choose to [laughs]. And I can't imagine anyone really disagreeing with a statement like that. JOËL: So, I know you choose to not always share everything about your life or sort of...I don't want to say bring your authentic self but, like, bring everything about yourself to the workplace. Do you have a sort of a heuristic for what you decide to share or not share? STEPHANIE: Yeah. I don't know if it's necessarily a heuristic so much as it's just what I do [laughs]. But I tend to do better with, like, smaller groups, and, actually, that's why I think pods has been working really well for me personally because I can share personal information just in a more intimate setting, which is helpful for me. And yeah, I tend to, like, find once, like, either Slack channels or Spaces, meetings are starting to get into the, like, 10, 11, 12 people territory is when I hold it back a little bit more, not because of any sort of, like, reason that I don't want to share. It's just, like, that's just not the venue for me. But I do love when other people are, like, open, even in, like, larger spaces like that. I appreciate when other people do it just to, you know, signal that it's okay [laughs]. And I enjoy throwing a reaction or responding in a thread about, you know, something that someone shared in a bigger channel. And I think that diversity is actually really helpful because it conveys that, like, there's different ways of existing online in your work environment and that they're all acceptable. What about you? How do you kind of choose where to share things about your personal life? JOËL: I think, kind of like you, I don't really have a heuristic. I just sort of go with gut feeling. I think I, sort of by nature, have always been maybe a little bit of having, like, separate professional and personal lives and keeping those a little bit more distinct. And, you know, there's some things that kind of cross over, like, oh, you know, I tried out this fun, new restaurant, or I did a cool activity over the weekend, or something like that. I think I've come to see that there can be a lot of value in sharing parts of yourself with other colleagues. And so, from time to time, I'll, like, maybe bring in something a little bit deeper. And, like you said, sometimes that's more easily done in a smaller context. And then yeah, for some things, it's like, okay, I'm going to share photos from a vacation in that, you know, quarterly newsletter. That's kind of fun. But also knowing that there's no pressure that's nice. STEPHANIE: Yeah. I think you're really good about finding the right avenues for that. I like, love when you show photos in the travel channel, even though I have that channel muted [laughs]. You'll, like, send me the link to the post in that channel. And yeah, I love that because it's a way for you to kind of, like, find the right place for it, and then also share it with any particular people if you choose to. JOËL: I think, also, personal connections can be a way to build deeper relationships, especially in smaller groups. And you can form deeper connections with colleagues over a particular project, or a particular technology, or a tech topic, or, you know, just a passion about mechanical keyboards, or something like that. But if you're people who chat kind of more on the regular for different things, maybe separate from a client project you're on or something like that, and you do find yourself exchanging a little bit more about, oh, you know, what you're doing in your life, or what are the things that are going on for you, that often does tend to build, I think, a deeper connection between colleagues, which can be really nice. STEPHANIE: Yeah. And I like that those relationships can also change. Like, there's different seasons in which you're more connected to some people and then less connected. Sometimes a colleague that you have shared interests with becomes someone that you kind of are in touch with more regularly, and then maybe you switch projects, and you aren't so much kind of as up to date. But, I don't know, I always think that there's, like, the right time for that kind of stuff, and it emerges. JOËL: I'm going to throw a bit of a buzzword at you, and I'd love to get your reaction. The idea of belonging, the feeling of belonging on a team, is that a good thing, something that we should seek out? And if so, how much of that is responsibility of, like, management or, like, a property of the team or the group to make you sort of feel that belonging? And how much of that is on you having to maybe disclose things about yourself or share a little bit of your personal life to, like, create that sense of belonging? STEPHANIE: Whoa. Yeah, that is a good way to frame it. I think there's a balance. There've been some, like, periods of my work life where I'm like, oh, I need more of a detachment from work and other times where I'm like, oh, I feel really disconnected, like, I want to feel like more of a part of this team. But I do think it's a management responsibility. And one thing that I know people to be cautious of is, you know, becoming too close at work. I don't know if your work being treated like a family, like, that kind of language can be a little bit borderline. JOËL: Almost manipulative. STEPHANIE: Right. Yeah, exactly. I do think there's something to be said about community at work and feeling like that kind of belonging, right? But also, that you can choose how much, like, you want to engage with that community and that being okay. I don't think it necessarily needs to be only through what you share about yourself. Like, you can have that sense of connection just by being a good colleague [chuckles], right? Like, even if the things you talk about are just within the realm of the project you're working on, like, there's still a sense of commitment and, yeah, in that relationship. And I think that is what matters when it comes to belonging. In the past, ways that I've seen that work well in regards to kind of how you share information is just, like, I don't know, share how you're doing. Like, you don't have to provide too many details. But it could be like, "Oh, I'm kind of distracted in my personal life right now, and that's why I wasn't able to get this done." People should be understanding of that, even if you don't kind of let them in on the more personal aspects of it. JOËL: Right. And you don't have to give any details, right? STEPHANIE: Yeah. JOËL: You should be in a place where people are comfortable with not knowing and not be like, "Ooh, what's going on with Stephanie's life? " STEPHANIE: [laughs] Yeah. But I do also think, like, the knowing that, like, something is going on is, like, also important context, right? Because you don't necessarily want that to impact the commitments you do have at work. JOËL: Right. And people tend to be a little bit more understanding if you're having to maybe shift some meetings around, or if you're struggling to focus on a particular day, or something like that. STEPHANIE: Yeah. 100%. JOËL: Yeah, we should normalize it of just like, "Hey, I'm having a hard day. I don't want to give details, but you know." STEPHANIE: Yeah. Yeah. I think a way that that is always kind of weird is how people communicate they're taking a sick day [laughs]. I actually had someone tell me that they really appreciated a time when I just said, "You know, I need to take care of myself today," and didn't really say anything else [laughs] about why. Because they're like, "Oh, like, that helped normalize this idea that, like, that is fine just kind of as is." There's no need to, you know, supply any additional reasoning. JOËL: Sometimes I feel like people almost feel the need to like, justify taking sick time. So, you've got to, like, say just how bad things are that now I'm actually taking sick time. STEPHANIE: Yeah, which is...that's not the point, right? You know, we have it because we need it [laughs]. So, yeah, I'm glad you mentioned that because I think that's actually a really good example of the ways that people, like, approach kind of bringing themselves to work like that. JOËL: Yeah, sometimes it's setting a boundary. An aspect I'm curious to look at is you, and I do a little bit of this with this podcast, right? Every week, we share a little bit of what's new in our world, and it goes out into the public internet. How do you tend to pick those topics and, like, how personal are you willing to get? STEPHANIE: Yeah. Oh, that's so hard. It's always hard [laughs], I think. I generally am pretty open. You know, I have talked about plans that I have for moving. I don't know, things about my gardening. I think I've also been a little vulnerable on the show before when I've, like, had a challenge, like, at work. But yeah, it's important, to me, I think, to be, like, true. Like, I think part of what our listeners like about this show is that we show up every week, and it's just a chat between two friends [laughs]. JOËL: Uh-huh. STEPHANIE: It also is kind of weird to know that it's just, like, out there, right? And I don't really know who's listening on the other side. I do know that, like, a lot of my friends listen. And, in some ways, I like to think that I'm talking to them, right? But yeah, sometimes I think about just, like, in a decade [laughs], it will still be out there. And on one hand, I think maybe it's kind of cool because I can listen back and be like, oh, like, that's what was going on for me in 2024. And other times I'm like, oh my God, what if I'm one day just, like, deeply embarrassed by things I've talked about on this show [laughs]? But that's a risk, I guess, I'm willing to take because I do think that the sense of connection that we foster with our audience is really meaningful. And it gives me a lot of joy whenever I meet a listener who's like, "Oh, you, you know, talked about this one thing, and I really related to it." And yeah, I guess that's what I do this for. What about you? JOËL: Yeah, I think kind of similar to you; tend to talk about things at work, interesting technical challenges, interesting sort of work, or even sometimes client-related challenges. Of course, you know, never calling out any clients by name, you know, talk about some hobbies and things like that. I think where I tend to draw the line a little bit is things that are a little bit more people-oriented in my personal life. So, I tend to not talk about family, and friends, and relationships, and things like that. And, you know, there are some times where there's like, those things intermix a little bit, where I'll, like, have shared, like, "This is what's new in my world." And then, like, off air, I'll follow up with you and say, "So, I didn't tell the whole story on air. STEPHANIE: [laughs] Yeah. JOËL: Here's what actually happened." Or, you know, "Here's this extra anecdote that I wanted you to know, but I didn't want everyone in the audience to hear." STEPHANIE: Yeah. I think the weirdest part for me, too, is I certainly have my, like, parasocial relationships with people that I follow on the internet [laughs], like, people on YouTube, or other podcasts, and stuff like that. But I haven't thought a whole lot about just, like, what that looks like for me as a host of a podcast. I think, kind of the size of the show now it feels right for me, where it's like I run into people who listen at conferences and stuff like that, but it is kind of contained to a work-related thing. So, that feels good because it, I think, for me, helps just give the work stuff a little bit of a deeper meaning, but otherwise isn't spilling over to my regular life. JOËL: And it's always fun when, you know, we get a listener email connecting to, you know, one of the random hobbies or something we've talked about and sharing a little bit of their experiences. I think last spring, I talked about getting a pair of bike shorts and, like, trying it out and seeing how that worked. And a listener called in and shared their experience with bike shorts, and, like, that's a lot of fun. It kind of creates that connection. So, I do enjoy that aspect. STEPHANIE: Yeah. And just to plug, you can write in to us at hosts@bikeshed.fm, and if you have anything you want to share that was inspired by what you heard us talk about on the show. JOËL: We'd love to have you. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Stephanie shares an intriguing discovery about the origins of design patterns in software, tracing them back to architect Christopher Alexander's ideas in architecture. Joël is an official member of the Boston bike share system, and he loves it. He even got a notification on the app this week: "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." #AchievementUnlocked, Joël! Joël and Stephanie transition into a broader discussion on data modeling within software systems, particularly how entities like companies, employees, and devices interconnect within a database. They debate the semantics of database relationships and the practical implications of various database design decisions, providing insights into the complexities of backend development. Christopher Alexander and Design Patterns (https://www.designsystems.com/christopher-alexander-the-father-of-pattern-language/) Rails guide to choosing between belongsto and hasone (https://edgeguides.rubyonrails.org/association_basics.html#choosing-between-belongs-to-and-has-one) Making impossible states impossible (https://www.youtube.com/watch?v=IcgmSRJHu_8) Transcript: We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. 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 learned a very interesting tidbit. I don't know if it's historical; I don't know if I would label it that. But, I recently learned about where the idea of design patterns in software came from. Are you familiar with that at all? JOËL: I read an article about that a while back, and I forget exactly, but there is, like, a design patterns movement, I think, that predates the software world. STEPHANIE: Yeah, exactly. So, as far as I understand it, there is an architect named Christopher Alexander, and he's kind of the one who proposed this idea of a pattern language. And he developed these ideas from the lens of architecture and building spaces. And he wrote a book called A Pattern Language that compiles, like, all these time-tested solutions to how to create spaces that meet people's needs, essentially. And I just thought that was really neat that software design adopted that philosophy, kind of taking a lot of these interdisciplinary ideas and bringing them into something technical. But also, what I was really compelled by was that the point of these patterns is to make these spaces comfortable and enjoyable for humans. And I have that same feeling evoked when I'm in a codebase that's really well designed, and I am just, like, totally comfortable in it, and I can kind of understand what's going on and know how to navigate it. That's a very visceral feeling, I think. JOËL: I love the kind of human-centric approach that you're using and the language that you're using, right? A place that is comfortable for humans. We want that for our homes. It's kind of nice in our codebases, too. STEPHANIE: Yeah. I have really enjoyed this framing because instead of just saying like, "Oh, it's quote, unquote, "best practice" to follow these design patterns," it kind of gives me more of a reason. It's more of a compelling reason to me to say like, "Following these design patterns makes the codebase, like, easier to navigate, or easier to change, or easier to work with." And that I can get kind of on board with rather than just saying, "This way is, like, the better way, or the superior way, or the way to do things." JOËL: At the end of the day, design patterns are a means to an end. They're not an end in of itself. And I think that's where it's very easy to get into trouble is where you're just sort of, I don't know, trying to rack up engineering points, I guess, for using a lot of design patterns, and they're not necessarily in service to some broader goal. STEPHANIE: Yeah, yeah, exactly. I like the way you put that. When you said that, for some reason, I was thinking about catching Pokémon or something like filling your Pokédex [laughs] with all the different design patterns. And it's not just, you know, like you said, to check off those boxes, but for something that is maybe a little more meaningful than that. JOËL: You're just trying to, like, hit the completionist achievement on the design patterns. STEPHANIE: Yeah, if someone ever reaches that, you know, gets that achievement trophy, let me know [laughs]. JOËL: Can I get a badge on GitHub for having PRs that use every single Gang of Four pattern? STEPHANIE: Anyway, Joël, what's new in your world? JOËL: So, on the topic of completing things and getting badges for them, I am a part of the Boston bike share...project makes it sound like it's a, I don't know, an exclusive club. It's Boston's bike share system. I have a subscription with them, and I love it. It's so practical. You can go everywhere. You don't have to worry about, like, a bike getting stolen or something because, like, you drop it off at a docking station, and then it's not your responsibility anymore. Yeah, it's very convenient. I love it. I got a notification on the app this week that said, "Congratulations. You have now visited 10% of all docking stations in the Boston metro area." STEPHANIE: Whoa, that's actually a pretty cool accomplishment. JOËL: I didn't even know they tracked that, and it's kind of cool. And the achievement shows me, like, here are all the different stations you've visited. STEPHANIE: You know what I think would be really fun? Is kind of the equivalent of a Spotify Wrapped, but for your biking in a year kind of around the city. JOËL: [laughs] STEPHANIE: That would be really neat, I think, just to be like, oh yeah, like, I took this bike trip here. Like, I docked at this station to go meet up with a friend in this neighborhood. Yeah, I think that would be really fun [laughs]. JOËL: You definitely see some patterns come up, right? You're like, oh yeah, well, you know, this is my commute into work every day. Or this is that one friend where, you know, every Tuesday night, we go and do this thing. STEPHANIE: Yeah, it's almost like a travelogue by bike. JOËL: Yeah. I'll bet there's a lot of really interesting information that could surface from that. It might be a little bit disturbing to find out that a company has that data on you because you can, like, pick up so much. STEPHANIE: That's -- JOËL: But it's also kind of fun to look at it. And you mentioned Spotify Wrapped, right? STEPHANIE: Right. JOËL: I love Spotify Wrapped. I have so much fun looking at it every year. STEPHANIE: Yeah. It's always kind of funny, you know, when products kind of track that kind of stuff because it's like, oh, like, it feels like you're really seen [laughs] in terms of what insights it's able to come up with. But yeah, I do think it's cool that you have this little badge. I would be curious to know if there's anyone who's, you know, managed to hit a hundred percent of all the docking stations. They must be a Boston bike messenger or something [laughs]. JOËL: Now that I know that they track it, maybe I should go for completion. STEPHANIE: That would be a very cool flex, in my opinion. JOËL: [laughs] And, you know, of course, they're always expanding the network, which is a good thing. I'll bet it's the kind of thing where you get, like, 99%, and then it's just really hard to, like, keep up. STEPHANIE: Yeah, nice. JOËL: But I guess it's very appropriate, right? For a podcast titled The Bike Shed to be enthusiastic about a bike share program. STEPHANIE: That's true. So, for today's topic, I wanted to pick your brain a little bit on a data modeling question that I posed to some other developers at thoughtbot, specifically when it comes to associations and associations through other associations [laughs]. So, I'm just going to kind of try to share in words what this data model looks like and kind of see what you think about it. So, if you had a company that has many employees and then the employee can also have many devices and you wanted to be able to associate that device with the company, so some kind of method like device dot company, how do you think you would go about making that association happen so that convenience method is available to you in the code? JOËL: As a convenience for not doing device dot employee dot company. STEPHANIE: Yeah, exactly. JOËL: I think a classic is, at least the other way, is that it has many through. I forget if you can do a belongs to through or not. You could also write, effectively, a delegation method on the device to effectively do dot employee dot company. STEPHANIE: Yeah. So, I had that same inkling as you as well, where at first I tried to do a belongs to through, but it turns out that belongs to does not support the through option. And then, I kind of went down the next path of thinking about if I could do a has one, a device has one company through employee, right? But the more I thought about it, the kind of stranger it felt to me in terms of the semantics of saying that a device has a company as opposed to a company having a device. It made more sense in plain English to think about it in terms of a device belonging to a company. JOËL: That's interesting, right? Because those are ways of describing relationships in sort of ActiveRecord's language. And in sort of a richer situation, you might have all sorts of different adjectives to describe relationships. Instead of just belongs to has many, you have things like an employee owns a device, an employee works for a company, you know because an employee doesn't literally belong to a company in the literal sense. That's kind of messed up. So, I think what ActiveRecord's language is trying to use is less trying to, like, hit maybe, like, the English domain language of how these things relate to, and it's more about where the foreign keys are in the database. STEPHANIE: Yeah. I like that point where even though, you know, these are the things that are available to us, that doesn't actually necessarily, you know, capture what we want it to mean. And I had gone to see what Rails' recommendation was, not necessarily for the situation I shared. But they have a section for choosing between which model should have the belongs to, as opposed to, like, it has one association on it. And it says, like you mentioned, you know, the distinction is where you place the foreign key, but you should kind of think about the actual meaning of the data. And, you know, we've talked a lot about, I think, domain modeling [chuckles] on the show. But their kind of documentation says that...the has something relationship says that one of something is yours, that it can, like, point back to you. And in the example I shared, it still felt to me like, you know, really, the device wanted to point to the company that it is owned by. And if we think about it in real-world terms, too, if that device, like, is company property, for example, then that's a way that that does make sense. But the couple of paths forward that I saw in front of me were to rework that association, maybe add a new column onto the device, and go down that path of codifying it at the database level. Or kind of maybe something as, like, an in-between step is delegating the method to the employee. And that's what I ended up doing because I wasn't quite ready to do that data migration. JOËL: Adding more columns is interesting because then you can run into sort of data consistency issues. Let's say on the device you have a company ID to see who the device belongs to. Now, there are sort of two different independent paths. You can ask, "Which company does this device belong to?" You can either check the company ID and then look it up in the company table. Or you can join on the employee and join the employee back under company. And those might give you different answers and that can be a problem with data consistency if those two need to stay in sync. STEPHANIE: Yeah, that is a good point. JOËL: There could be scenarios where those two are allowed to diverge, right? You can imagine a scenario where maybe a company owns the device, but an employee of a potentially different company is using the device. And so, now it's okay to have sort of two different chains because the path through the employee is about what company is using our devices versus which company actually owns them. And those are, like, two different kinds of relationships. But if you're trying to get the same thing through two different paths of joining, then that can set you up for some data inconsistency issues. STEPHANIE: Wow. I really liked what you said there because I don't think enough thought goes into the emergent relationships between models after they've been introduced to a codebase. At least in my experience, I've seen a lot of thought go up front into how we might want to model an ActiveRecord, but then less thought into seeing what patterns kind of show up over time as we introduce more functionality to these models, and kind of understand how they should exist in our codebase. Is that something that you find yourself kind of noticing? Like, how do you kind of pick up on the cue that maybe there's some more thought that needs to happen when it comes to existing database tables? JOËL: I think it's something that definitely is a bit of a red flag, for me, is when there are multiple paths to connect to sort of establish a relationship. So, if I were to draw out some sort of, like, diagram of the models, boxes, and arrows or something like that, and then I could sort of overlay different paths through that diagram to connect two models and realize that those things need to be in sync, I think that's when I started thinking, ooh, that's a potential danger. STEPHANIE: Yeah, that's a really great point because, you know, the example I shared was actually a kind of contrived one based on what I was seeing in a client codebase, not, you know, I'm not actually working with devices, companies, and employees [laughs]. But it was encoded as, essentially, a device having one company. And I ended up drawing it out because I just couldn't wrap my head around that idea. And I had, essentially, an arrow from device pointing to company when I could also see that you could go take the path of going through employee [laughs]. And I was just curious if that was intentional or was it just kind of a convenient way to have that direct method available? I don't currently have enough context to determine but would be something I want to pay attention to. Like you said, it does feel like, if not a red flag, at least an orange one. JOËL: And there's a whole kind of science to some of this called database normalization, where they're sort of, like, they all have rather arcane names. They're the first normal form, the second normal form, the third normal form, you know, it goes on. If you look at the definition, they're all also a little bit arcane, like every element in a relation must depend solely upon the primary key. And you're just like, well, what does that mean? And how do I know if my table is compliant with that? So, I think it's worth, if you're Googling for some of these, find an article that sort of explains these a little bit more in layman's terms, if you will. But the general idea is that there are sort of stricter and stricter levels of the amount of sort of duplicate sources of truth you can have. In a sense, it's almost like DRY but for databases, and for your database schema in particular. Because when you have multiple sources of truth, like who does this device belong to, and now you get two different answers, or three different answers, now you've got a data corruption issue. Unlike bugs in code where it's, you know, it can be a problem because the site is down, or users have incorrect behavior, but then you can fix it later, and then go to production, and disruption to your clients is the worst that happened, this sort of problem in data is sometimes unrecoverable. Like, it's just, hey, -- STEPHANIE: Whoa, that sounds scary. JOËL: Yeah, no, data problems scare me in a way that code problems don't. STEPHANIE: Whoa. Could you...I think I interrupted you. But where were you going to go about once you have corrupted data? Like, it's unrecoverable. What happens then? JOËL: Because, like, if I look at the database, do I know who the real owner of this...if I want to fix it, let's say I fix my schema, but now I've got all this data where I've got devices that have two different owners, and I don't know which one is the real one. And maybe the answer is, I just sort of pick one and say, "Oh, the one that was through this association is sort of the canonical one, and we can just sort of ignore the other one." Do I have confidence in that decision? Well, maybe depending on some of the other context maybe, I'm lucky that I can have that. The doomsday scenario is that it's a little bit of one, a little bit of the other because there were different code paths that would write to one way or another. And there's no real way of knowing. If there's not too many devices, maybe I do an audit. Maybe I have to, like, follow up with all of my customers and say, "Hey, can you tell me which ones are really your devices?" That's not going to scale. Like, real worst case scenario, you almost have to do, like, a bit of a bankruptcy, where you say, "Hey, all the data prior to this date there's a bit of a question mark on it. We're not a hundred percent sure about it." And that does not feel great. So, now you're talking about mitigation strategies. STEPHANIE: Oof. Wow. Yeah, you did make it sound [laughs] very scary. I think I've kind of been on the periphery of a situation like this before, where it's not just that we couldn't trust the code. It's that we couldn't trust the data in the database either to tell us how things work, you know, for our users and should work from a product perspective. And I was on a previous client project where they had to, yeah, like, hire a bunch of people to go through that data and kind of make those determinations, like you said, to kind of figure out it out for, you know, all of these customers to determine the source of truth there. And it did not sound like an easy feat at all, right? That's so much time and investment that you have to put into that once you get to that point. JOËL: And there's a little bit of, like, different problems at different layers. You know, at the database layer, generally, you want all of that data to be really in a sort of single source of truth. Sometimes that makes it annoying to query because you've got to do all these joins. And so, there are various denormalization strategies that you can use to make that. Or sometimes it's a risk you're going to take. You're going to say, "Look, this table is not going to be totally normalized. There's going to be some amount of duplication, and we're comfortable with the risk if that comes up." Sometimes you also build layers of abstractions on top, so you might have your data sort of at rest in database tables fully normalized and separated out, but it's really clunky to query. So, you build out a database view on top of that that returns data in sort of denormalized fashion. But that's okay because you can always get your correct answer by querying the underlying tables. STEPHANIE: Wow. Okay. I have a lot of thoughts about this because I feel like database normalization, and I guess denormalization now, are skills that I am certainly not an expert at. And so, when it comes to, like, your average developer, how much do you think that people need to be thinking about this? Or what strategies do you have for, you know, a typical Rails dev in terms of how deep they should go [laughs]? JOËL: So, the classic advice is you probably want to go to, like, third to fourth normal form, usually three. There's also like 3.5 for some reason. That's also, I think, sometimes called BNF. Anyway, sort of levels of how much you normalize. Some of these things are, like, really, really basic things that Rails just builds into its defaults with that convention over configuration, so things like every table should have a primary key. And that primary key should be something that's fixed and unique. So, don't use something like combination of first name, last name as your primary key because there could be multiple people with the same name. Also, people change their names, and that's not great. But it's great that people can change their names. It's not great to rely on that as a primary key. There are things like look for repeating columns. If you've got columns in your schema with a number prefix at the end, that's probably a sign that you want to extract a table. So, I don't know, you have a movie, and you want to list the actors for a movie. If your movie table has actor 1, actor 2, actor 3, actor 4, actor 5, you know, like, all the way up to actor 20, and you're just like, "Yeah, no, we fill, like, actor 1 through N, and if there's any space left over, we just put nulls in those columns," that's a pretty big sign that, hey, why don't you instead have a, like, actor's table, and then make a, like, has many association? So, a lot of the, like, really basic normalization things, I think, are either built into Rails or built into sort of best practices around Rails. I think something that's really useful for developers to get as a sense beyond learning the actual different normal forms is think about it like DRY for your schema. Be wary of sort of multiple sources of truth for your data, and that will get you most of the way there. When you're designing sort of models and tables, oftentimes, we think of DRY more in terms of code. Do you ever think about that a little bit in terms of your tables as well? STEPHANIE: Yeah, I would say so. I think a lot of the time rather than references to another table just starting to grow on a certain model, I would usually lean towards introducing a join table there, both because it kind of encapsulates this idea that there is a connection, and it makes the space for that idea to grow if it needs to in the future. I don't know if I have really been disciplined in thinking about like, oh, you know, there should really...every time I kind of am designing my database tables, thinking about, like, there should only be one source of truth. But I think that's a really good rule of thumb to follow. And in fact, I can actually think of an example right now where we are a little bit tempted to break that rule. And you're making me reconsider [laughter] if there's another way of doing so. One thing that I have been kind of appreciative of lately is on my current client project; there's just, like, a lot of data. It's a very data-intensive and sensitive application. And so, when we introduce migrations, those PRs get tagged for review by someone over from the DevOps side, just to kind of provide some guidance around, you know, making sure that we're setting up our models to scale well. One of the things that he's been asking me on my couple of code changes I introduced was, like, when I introduced an index, like, it happened to be, like, a composite index with a couple of different columns, and the particular order of those columns mattered. And he kind of prompted me to, like, share what my use cases for this index were, just to make sure that, like, some thought went into it, right? Like, it's not so much that the way that I had done it was wrong, but just that I had, like, thought about it. And I like that as a way of kind of thinking about things at the abstraction that I need to to do my dev work day to day and then kind of mapping that to, like you were saying, those best practices around keeping things kind of performant at the database level. JOËL: I think there's a bit of a parallel world that people could really benefit from dipping a toe in, and that's sort of the typed programming world, this idea of making impossible states impossible or making illegal states unrepresentable. That in the sort of now it's not schemas of database tables or schemas of types that you're creating but trying to prevent data coming into a state where someone could plausibly construct an instance of your object or your type that would be nonsensical in the context of your app, kind of trying to lock that down. And I think a lot of the ways that people in those communities think about...in a sense, it's kind of like database normalization for developers. So, if you're not wanting to, like, dip your toe in more of the sort of database-centric world and, like, read an article from a DBA, it might be worthwhile to look at some of those worlds as well. And I think a great starting point for that is a talk by Richard Feldman called Making Impossible States Impossible. It's for the Elm language. And there are equivalents, I think, in many others as well. STEPHANIE: That's really cool that you are making that connection. I know we've kind of briefly talked about workshops in the past on the show. But if there were a workshop for, you know, that kind of database normalization for developers, I would be the first to sign up [laughs]. JOËL: Hint, hint, RailsConf idea. There's something from your original question that I think is interesting to circle back to, and that's the fact that it was awkward to work through in Ruby to do the work that you wanted to do because the tables were laid out in a certain way. And sometimes, there's certain ways that you need the tables to be in order to be sort of safe to represent data, but they're not the optimal way that we would like to interact with them at the Ruby level. And I think it's okay for not everything in Ruby to be 100% reflective of the structure of the tables underneath. ActiveRecord gives us a great pattern, but everything is kind of one-to-one. And it's okay to layer on some things on top, add some extra methods to build some, like, connections in Ruby that rely on this normalized data underneath but that make life easier for you, or they better just represent or describe the relationships that you have. STEPHANIE: 100%. I was really compelled by your idea of introducing helpers that use more descriptive adjectives for what that relationship is like. We've talked about how Rails abstracted things from the database level, you know, for our convenience, but that should not stop us from, like, leaning on that further, right? And kind of introducing our own abstractions for those connections that we see in our domain. So, I feel really inspired. I might even kind of reconsider the way I handled the original example and see what I can make of it. JOËL: And I think your original solution of doing the delegation is a great example of this as well. You want the idea that a device belongs to a company or has an association called company, and you just don't want to go through that long chain, or at least you don't want that to be visible as an implementation detail. So, in this case, you delegate it through a chain of methods in Ruby. It could also be that you have a much longer chain of tables, and maybe they don't all have associations in Rails and all that. And I think it would be totally fine as well to define a method on an object where, I don't know, a device, I don't know, has many...let's call it technicians, which is everybody who's ever touched this device or, you know, is on a log somewhere for having done maintenance. And maybe that list of technicians is not a thing you can just get through regular Rails associations. Maybe there's a whole, like, custom query underlying that, and that's okay. STEPHANIE: Yeah, as you were saying that, I was thinking about that's actually kind of, like, active models are the great spot to put those methods and that logic. And I think you've made a really good case for that. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Joël shares his experience with the dry-rb suite of gems, focusing on how he's been using contracts to validate input data. Stephanie relates to Joël's insights with her preparation for RailsConf, discussing her methods for presenting code in slides and weighing the aesthetics and functionality of different tools like VS Code and Carbon.sh. She also encounters a CI test failure that prompts her to consider the implications of enforcing specific coding standards through CI processes. The conversation turns into a discussion on managing coding standards and tools effectively, ensuring that automated systems help rather than hinder development. Joël and Stephanie ponder the balance between enforcing strict coding standards through CI and allowing developers the flexibility to bypass specific rules when necessary, ensuring tools provide valuable feedback without becoming obstructions. Transcript: AD: We're excited to announce a new workshop series for helping you get that startup idea you have out of your head and into the world. It's called Vision to Value. Over a series of 90-minute working sessions, you'll work with a thoughtbot product strategist and a handful of other founders to start testing your idea in the market and make a plan for building an MVP. Join for all seven of the weekly sessions, or pick and choose the ones that address your biggest challenge right now. Learn more and sign up at tbot.io/visionvalue. STEPHANIE: Hello and welcome to another episode of the Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been working on a project that uses the dry-rb suite of gems. And one of the things we're doing there is we're validating inputs using this concept of a contract. So, you sort of describe the shape and requirements of this, like hash of attributes that you get, and it will then tell you whether it's valid or not, along with error messages. We then want to use those to eventually build some other sort of value object type things that we use in the app. And because there's, like, failure points at multiple places that you have to track, it gets a little bit clunky. And I got to thinking a little bit about, like, forget about the internal machinery. What is it that I would actually like to happen here? And really, what I want is to say, I've got this, like, bunch of attributes, which may or may not be correct. I want to pass them into a method, and then either get back a value object that I was hoping to construct or some kind of error. STEPHANIE: That sounds reasonable to me. JOËL: And then, thinking about it just a little bit longer, I was like, wait a minute, this idea of, like, unstructured input goes into a method, you get back something more structured or an error, that's kind of the broad definition of parsing. I think what I'm looking for is a parser object. And this really fits well with a style of processing popularized in the functional programming community called parse, don't validate the idea that you use a parser like this to sort of transform data from more loose to more strict values, values where you can have more assumptions. And so, I create an object, and I can take a contract. I can take a class and say, "Attempt to take the following attributes. If they're valid according to the construct, create this classroom." And it, you know, does a bunch of error handling and some...under the hood, dry-rb does all this monad stuff. So, I handled that all inside of the object, but it's actually really nice. STEPHANIE: Cool. Yeah, I had a feeling that was where you were going to go. A while back, we had talked about really impactful articles that we had read over the course of the year, and you had shared one called Parse, Don't Validate. And that heuristic has actually been stuck in my head a little bit. And that was really cool that you found an opportunity to use it in, you know, previously trying to make something work that, like, you weren't really sure kind of how you wanted to implement that. JOËL: I think I had a bit of a light bulb moment as I was trying to figure this out because, in my mind, there are sort of two broad approaches. There's the parse, don't validate where you have some inputs, and then you transform them into something stricter. Or there's more of that validation approach where you have inputs, you verify that they're correct, and then you pass them on to someone else. And you just say, "Trust me, I verified they're in the right shape." Dry-rb sort of contracts feel like they fit more under that validation approach rather than the parse, don't validate. Where I think the kind of the light bulb turned on for me is the idea that if you pair a validation step and an object construction step, you've effectively approximated the idea of parse, don't validate. So, if I create a parser object that says, in sort of one step, I'm going to validate some inputs and then immediately use them if they're valid to construct an object, then I've kind of done a parse don't validate, even though the individual building blocks don't follow that pattern. STEPHANIE: More like a parse and validate, if you will [laughs]. I have a question for you. Like, do you own those inputs kind of in your domain? JOËL: In this particular case, sort of. They're coming from a form, so yes. But it's user input, so never trust that. STEPHANIE: Gotcha. JOËL: I think you can take this idea and go a little bit broader as well. It doesn't have to be, like, the dry-rb-related stuff. You could do, for example, a JSON schema, right? You're dealing with the input from a third-party API, and you say, "Okay, well, I'm going to have a sort of validation JSON schema." It will just tell you, "Is this data valid or not?" and give you some errors. But what if you paired that with construction and you could create a little parser object, if you wanted to, that says, "Hey, I've got a payload coming in from a third-party API, validate it against this JSON schema, and attempt to construct this shopping cart object, and give me an error otherwise." And now you've sort of created a nice, little parse, don't validate pipeline which I find a really nice way to deal with data like that. STEPHANIE: From a user perspective, I'm curious: Does this also improve the user experience? I'm kind of wondering about that. It seems like it could. But have you explored that? JOËL: This is more about the developer experience. STEPHANIE: Got it. JOËL: The user experience, I think, would be either identical or, you know, you can play around with things to display better errors. But this is more about the ergonomics on the development side of things. It was a little bit clunky to sort of assemble all the parts together. And sometimes we didn't immediately do both steps together at the same time. So, you might sort of have parameters that we're like, oh, these are totally good, we promise. And we pass them on to someone else, who passes them on to someone else. And then, they might try to do something with them and hope that they've got the data in the right shape. And so, saying, let's co-locate these two things. Let's say the validation of the inputs and then the creation of some richer object happen immediately one after another. We're always going to bundle them together. And then, in this particular case, because we're using dry-rb, there's all this monad stuff that has to happen. That was a little bit clunky. We've sort of hidden that in one object, and then nobody else ever has to deal with that. So, it's easier for developers in terms of just, if you want to turn inputs into objects, now you're just passing them into one object, into one, like, parser, and it works. But it's a nicer developer experience, but also there's a little bit more safety in that because now you're sort of always working with these richer objects that have been validated. STEPHANIE: Yeah, that makes sense. It sounds very cohesive because you've determined that these are two things that should always happen together. The problems arise when they start to actually get separated, and you don't have what you need in terms of using your interfaces. And that's very nice that you were able to bundle that in an abstraction that makes sense. JOËL: A really interesting thing I think about abstractions is sometimes thinking of them as the combination of multiple other things. So, you could say that the combination of one thing and another thing, and all of a sudden, you have a new sort of combo thing that you have created. And, in this case, I think the combination of input validation and construction, and, you know, to a certain extent, error handling, so maybe it's a combination of three things gives you a thing you can call a parser. And knowing that that combination is a thing you can put a name on, I think, is really powerful, or at least it felt really powerful to me when that light bulb turned on. STEPHANIE: Yeah, it's kind of like the whole is greater than the sum of its parts. JOËL: Yeah. STEPHANIE: Cool. JOËL: And you and I did an episode on Specialized Vocabulary a while back. And that power of naming, saying that, oh, I don't just have a bunch of little atomic steps that do things. But the fact that the combination of three or four of them is a thing in and of itself that has a name that we can talk about has properties that we're familiar with, all of a sudden, that is a really powerful way to think about a system. STEPHANIE: Absolutely. That's very exciting. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I am plugging away at my RailsConf talk, and I reached the point where I'm starting to work on slides. And this talk will be the first one where I have a lot of code that I want to present on my slides. And so, I've been playing around with a couple of different tools to present code on slides or, I guess, you know, just being able to share code outside of an editor. And the two tools I'm trying are...VS Code actually has a copy with syntax functionality in its command palette. And so, that's cool because it basically, you know, just takes your editor styling and applies it wherever you paste that code snippet. JOËL: Is that a screenshot or that's, like, formatted text that you can paste in, like, a rich text editor? STEPHANIE: Yeah, it's the latter. JOËL: Okay. STEPHANIE: That was nice because if I needed to make changes in my slides once I had already put them there, I could do that. But then the other tool that I was giving a whirl is Carbon.sh. And that one, I think, is pretty popular because it looks very slick. It kind of looks like a little Mac window and is very minimal. But you can paste your code into their text editor, and then you can export PNGs of the code. So, those are just screenshots rather than editable text. And I [chuckles] was using that, exported a bunch of screenshots of all of my code in various stages, and then realized I had a typo [laughs]. JOËL: Oh no! STEPHANIE: Yeah, so I have not got around to fixing that yet. That was pretty frustrating because now I would have to go back and regenerate all of those exports. So, that's kind of where I'm at in terms of exploring sharing code. So, if anyone has any other tools that they would use and recommend, I am all ears. JOËL: How do you feel about balancing sort of the quantity of code that you put on a slide? Do you tend to go with, like, a larger code slide and then maybe, like, highlight certain sections? Do you try to explain ideas in general and then only show, like, a couple of lines? Do you show, like, maybe a class that's got ten lines, and that's fine? Where do you find that balance in terms of how much code to put on a slide? Because I feel like that's always the big dilemma for me. STEPHANIE: Yeah. Since this is my first time doing it, like, I really have no idea how it's going to turn out. But what I've been trying is focusing more on changes between each slide, so the progression of the code. And then, I can, hopefully, focus more on what has changed since the last snippet of code we were looking at. That has also required me to be more fiddly with the formatting because I don't want essentially, like, the window that's containing the code to be changing sizes [laughs] in between slide transitions. So, that was a little bit finicky. And then, there's also a few other parts where I am highlighting with, like, a border or something around certain texts that I will probably pause and talk about, but yeah, it's tough. I feel like I've seen it done well, but it's a lot harder to and a lot more effort to [laughs] do in practice, I'm finding. JOËL: When someone does it well, it looks effortless. And then, when somebody does it poorly, you're like, okay, I'm struggling to connect with this talk. STEPHANIE: Yep. Yep. I hear that. I don't know if you would agree with this, but I get the sense that people who are able to make that look effortless have, like, a really deep and thorough understanding of the code they're showing and what exactly they think is important for the audience to pay attention to and understand in that given moment in their talk. That's the part that I'm finding a lot more work [laughs] because just thinking about, you know, the code I'm showing from a different lens or perspective. JOËL: How do you sort of shrink it down to only what's essential for the point that you're trying to make? And then, more broadly, not just the point you're trying to make on this one slide, but how does this one slide fit into the broader narrative of the story you're trying to tell? STEPHANIE: Right. So, we'll see how it goes for me. I'm sure it's one of those things that takes practice and experience, and this will be my first time, and we'll learn something from it. JOËL: That's exciting. So, this is RailsConf in Detroit this year, I believe, May 7th through 9th. STEPHANIE: Yep. That's right. So, recently on my client work, I encountered a CI failure on a PR of mine that I was surprised by. And basically, I had introduced a new association on a model, and this CI failure was saying like, "Hey, like, we see that you introduced this association. You should consider adding this to the presenter for this model." And I hadn't even known that that presenter existed [laughs]. So, it was kind of interesting to get a CI failure nudging me to consider if I need to be, like, making a different, you know, this other change somewhere else. JOËL: That's a really fun use of CI. Do you think that was sort of helpful for you as a newer person on that codebase? Or was it more kind of annoying and, like, okay, this CI is over the top? STEPHANIE: You know, I'm not sure [laughs]. For what it's worth, this presenter was actually for their admin dashboard, essentially. And so, the goal of what this workflow was trying to do was help folks who are using the admin dashboard have, like, all of the capabilities they need to do that job. And it makes sense that as you add behavior to your app, sometimes those things could get missed in terms of supporting, you know, not just your customers but developers, support product, you know, the other users of your app. So, it was cool. And that was, you know, something that they cared enough to enforce. But yeah, I think there maybe is a bit of a slippery slope or at least some kind of line, or it might even be pretty blurry around what should our test failures really be doing. JOËL: And CI is interesting because it can be a lot more than just tests. You can run all sorts of things. You can run a linter that fails. You could run various code quality tools that are not things like unit tests. And I think those are all valid uses of the CI process. What's interesting here is that it sounds like there were two systems that needed to stay in sync. And this particular CI check was about making sure that we didn't accidentally introduce code that would sort of drift apart in those two places. Does that sound about right? STEPHANIE: Yeah, that does sound right. I think where it gets a little fuzzy, for me, is whether that kind of check was for code quality, was for a standard, or for a policy, right? It was kind of saying like, hey, like, this is the way that we've enforced developers to keep those two things from drifting. Whereas I think that could be also handled in different ways, right? JOËL: Yeah. I guess in terms of, like, keeping two things in sync, I like to do that at almost, like, a code level, if possible. I mean, maybe you need a single source of truth, and then it just sort of happens automatically. Otherwise, maybe doing it in a way that will yell at you. So, you know, maybe there's a base class somewhere that will raise an error, and that will get caught by CI, or, you know, when you're manually testing and like, oh yeah, I need to keep this thing in sync. Maybe you can derive some things or get fancy with metaprogramming. And the goal here is you don't have a situation where someone adds a new file in one place and then they accidentally break an admin dashboard because they weren't aware that you needed these two files to be one-to-one. If I can't do it just at a code level, I have done that before at, like, a unit test level, where maybe there's, like, a constant somewhere, and I just want to assert that every item in this constant array has a matching entry somewhere else or something like that, so that you don't end up effectively crashing the site for someone else because that is broken behavior. STEPHANIE: Yeah, in this particular case, it wasn't necessarily broken. It was asking you "Hey, should this be added to the admin presenter?" which I thought was interesting. But I also hear what you're saying. It actually does remind me of what we were talking about earlier when you've identified two things that should happen, like mostly together and whether the code gives you affordances to do that. JOËL: So, one of the things you said is really interesting, the idea that adding to the presenter might have been optional. Does that mean that CI failed for you but that you could merge anyway, or how does that work? STEPHANIE: Right. I should have been more clear. This was actually a test failure, you know, that happened to be caught by CI because I don't run [laughs] the whole test suite locally. JOËL: But it's an optional test failure, so you're allowed to let that test fail. STEPHANIE: Basically, it told me, like, if I want this to be shown in the presenter, add it to this method, or if not, add it to...it was kind of like an allow list basically. JOËL: I see. STEPHANIE: Or an ignore list, yeah. JOËL: I think that kind of makes sense because now you have sort of, like, a required consistency thing. So, you say, "Our system requires you...whenever you add a file in this directory, you must add it to either an allow list or an ignore list, which we have set up in this other file." And, you know, sometimes you might forget, or sometimes you're new, and it's your first time adding a file in this directory, and you didn't remember there's a different place where you have to effectively register it. That seems like a reasonable check to have in place if you're relying on these sort of allow lists for other parts of the system, and you need to keep them in sync. STEPHANIE: So, I think this is one of the few instances where I might disagree with you, Joël. What I'm thinking is that it feels a bit weird to me to enforce a decision that was so far away from the code change that I made. You know, you're right. On one hand, I am newer to this codebase, maybe have less of that context of different features, things that need to happen. It's a big app. But I almost think this test reinforces this weird coupling of things that are very far away from each other [laughs]. JOËL: So, it's maybe not the test itself you object to rather than the general architecture where these admin presenters are relying on these other objects. And by you introducing a file in a totally different part of the app, there's a chance that you might break the admin, and that feels weird to you. STEPHANIE: Yeah, that does feel weird to me. And then, also that this implementation is, like, codified in this test, I guess, as opposed to a different kind of, like, acceptance test, rather than specifying specifically like, oh, I noticed, you know, you didn't add this new association or attribute to either the allow list or the ignore list. Maybe there is a more, like, higher level test that could steer us in keeping the features consistent without necessarily dictating, like, that it needs to happen in these particular methods. JOËL: So, you're talking something like doing an integration test rather than a unit test? Or are you talking about something entirely different? STEPHANIE: I think it could be an integration test or a system test. I'm not sure exactly. But I am wondering what options, you know, are out there for helping keeping standards in place without necessarily, like, prescribing too much about, like, how it needs to be done. JOËL: So, you used the word standard here, which I tend to think about more in terms of, like, code style, things like that. What you're describing here feels a little bit less like a standard and more of what I would call a code invariant. STEPHANIE: Ooh. JOËL: It's sort of like in this architecture the way we've set up, there must always be sort of one-to-one matching between files in this directory and entries in this array. Now, that's annoying because they're sort of, like, two different places, and they can vary independently. So, locking those two in sync requires you to do some clunky things, but that's sort of the way the architecture has been designed. These two things must remain one-to-one. This is an invariant we want in the app. STEPHANIE: Can you define invariant for me [laughs], the way that you're using it here? JOËL: Yeah, so something that is required to be true of all elements in this class of things, sort of a rule or a law that you're applying to the way that these particular bits of code need to behave. So, in this case, the invariant is every file in this directory must have a matching entry in this array. There's a lot of ways to enforce that. The sort of traditional idea is sort of pushing a lot of that checking...they'll sometimes talk about pushing errors to the left. So, if you can handle this earlier in the sort of code execution pipeline, can you do it maybe with a type system if you're in a type language? Can you do it with some sort of input validation at runtime? Some languages have the concept of contracts, so maybe you enforce invariants using that. You could even do something really ad hoc in Ruby, where you might say, "Hey, at boot time, when we load this particular array for the admin, just load this directory. Make sure that the entries in the array match the entries in the directory, and if they don't, raise an error." And I guess you would catch that probably in CI just because you tried to run your test suite, and you'd immediately get this boot error because the entries don't match. So, I guess it kind of gets [inaudible 22:36] CI, but now it's not really a dedicated test anymore. It's more of, like, a property of the system. And so, in this case, I've sort of shifted the error checking or the checking of this invariant more into the architecture itself rather than in, like, things that exercise the architecture. But you can go the other way and say, "Well, let's shift it out of the architecture into tests," or maybe even beyond that, into, like, manual QA or, you know, other things that you can do to verify it. STEPHANIE: Hmm. That is very compelling to me. JOËL: So, we've been talking so far about the idea of invariants, but the thing about invariants is that they don't vary. They're always true. This is a sort of fundamental rule of how this system works. The class of problems that I often struggle with how to deal with in these sorts of situations are rules that you only sometimes want to apply. They're not consistent. Have you ever run into things like that? STEPHANIE: Yeah, I have. And I think that's what was compelling to me about what you were sharing about code invariance because I wasn't totally convinced this particular situation was a very clear and absolute rule that had been decided, you know, it seemed a little bit more ambiguous. When you're talking about, like, applying rules that sometimes you actually don't want to apply, I think of things like linters, where we want to disable, you know, certain rules because we just can't get around implementing the way we want to while following those standards. Or maybe, you know, sometimes you just have to do something that is not accessible [laughs], not that that's what I would recommend, but in the case where there aren't other levers to change, you maybe want to disable some kind of accessibility check. JOËL: That's always interesting, right? Because sometimes, you might want, like, the idea of something that has an escape hatch in it, but that immediately adds a lot of complexity to things as well. This is getting into more controversial territory. But I read a really compelling article by Jeroen Engels about how being able to, like, locally disable your linter for particular methods actually makes your code, but also the linter itself, a worse tool. And it really kind of made me rethink a little bit of how I approach linters as a tool. STEPHANIE: Ooh. JOËL: And what makes sense in a linter. STEPHANIE: What was the argument for the linter being a worse tool by doing that? JOËL: You know, it's funny that you ask because now I can't remember, and it's been a little while since I've read the article. STEPHANIE: I'll have to revisit it after the show [laughs]. JOËL: Apparently, I didn't do the homework for this episode, but we'll definitely link to that article in the show notes. STEPHANIE: So, how do you approach either introducing a new rule to something like a linter or maybe reconsidering an existing rule? Like, how would you go about finding, like, consensus on that from your team? JOËL: That varies a lot by organizational culture, right? Some places will do it top-down, some of them will have a broader conversation and come to a consensus. And sometimes you just straight up don't get a choice. You're pulling in a tool like standard rb, and you're saying, "Look, we don't want to have a discussion about every little style thing, so whatever, you know, the community has agreed on for the standard rb linter is the style we're using. There are no discussions. Do what the linter tells you." STEPHANIE: Yeah, that's true. I think I have to adapt to whatever, you know, client culture is like when I join new projects. You know, sometimes I do see people being like, "Hey, I think it's kind of weird that we have this," or, "Hey, I've noticed, for example, oh, we're merging focused RSpec tests. Like, let's introduce a rule to make sure that that doesn't happen." I also think that a different approach is for those things not to be enforced at all by automation, but we, you know, there are still guidelines. I think the thoughtbot guides are an example of pretty opinionated guidelines around style and syntax. But I don't think that those kinds of things would, you know, ever be, like, enforced in a way that would be blocking. JOËL: Those are kind of hard because they're not as consistent as you would think, so it's not a rule you can apply every time. It's more of a, here's some things to maybe keep in mind. Or if you're writing code in this way, think about some of the edge cases that might happen, or don't default to writing it in this way because things might go wrong. Make sure you know what you're doing. I love the phrase, "Must be able to justify this," or sometimes, "Must convince your pair that this is okay." So, default to writing in style A, avoid style B unless you can have a compelling reason to do so and can articulate that on your PR or, you know, convince your pair that that's the right way to go. STEPHANIE: Interesting. It's kind of like the honor system, then [laughs]. JOËL: And I think that's sort of the general way when you're working with developers, right? There's a lot of areas where there is ambiguity. There is no single best way to do it. And so, you rely on people's expertise to build systems that work well. There are some things where you say, look, having conversations about these things is not useful. We want to have some amount of standardization or uniformity about certain things. Maybe there's invariance you want to hold. Maybe there's certain things we're, like, this should never get to production. Whenever you've got these, like, broad sweeping statements about things should be always true or never true, that's a great time to introduce something like a linting rule. When it's more up to personal judgment, and you just want to nudge that judgment one way or another, then maybe it's better to have something like a guide. STEPHANIE: Yeah, what I'm hearing is there is a bit of a spectrum. JOËL: For sure. From things that are always true to things that are, like, sometimes true. I think I'm sort of curious about the idea of going a level beyond that, though, beyond things like just code style or maybe even, like, invariance you want to hold or something, being able to make suggestions to developers based off the code that is written. So, now you're applying more like heuristics, but instead of asking a human to apply those heuristics at code review time and leave some comments, maybe there's a way to get automated feedback from a tool. STEPHANIE: Yeah, I think we had mentioned code analysis tools earlier because some teams and organizations include those as part of their CI builds, right? And, you know, even Brakeman, right? Like, that's an analysis tool for security. But I can't recall if I've seen an organization use things like Flog metrics which measure code complexity in things like that. How would you feel if that were a check that was blocking your work? JOËL: So, I've seen things like that be used if you're using, like, the Code Climate plugin for GitHub. And Code Climate internally does effectively flog and other things that are fancier on your code quality. And so, you can set a threshold to say, hey, if complexity gets higher than a certain amount, fail the build. You can also...if you're doing things via GitHub, what's nice is that you can do effectively non-blocking comments. So, instead of failing CI to say, "Hey, this method looks really complex. You cannot merge until you have made this method less complex," maybe the sort of, like, next step up in ambiguity is to just leave a comment on a PR from a tool and say, "Hey, this method here is looking really complex. Consider breaking it up." STEPHANIE: Yeah, there is a tool that I've seen but not used called Danger, and its tagline is, Stop saying, "You forgot to..." in code review [laughs]. And it basically does that, what you were saying, of, like, leaving probably a suggestion. I can imagine it's blocking, but a suggestive comment that just automates that rather than it being a manual process that humans have to remember or notice. JOËL: And there's a lot of things that could be specific to your organization or your architecture. So, you say, "Hey, you introduced a file here. Would you consider also making an entry to this presenter file so that it's editable on the admin?" And maybe that's a better place to handle that. Just a comment. But you wouldn't necessarily want every code reviewer to have to think about that. STEPHANIE: So, I do think that I am sometimes not necessarily suspicious, but I have also seen tools like that end up just getting in the way, and it just becomes something you ignore. It's something you end up always using the escape hatch for, or people just find ways around it because they're harming more than they're helping. Do you have any thoughts about how to kind of keep those things in check and make sure that the tools we introduce genuinely are kind of helping the organization do the right thing rather than kind of being these perhaps arbitrary blockers? JOËL: I'm going to throw a fancy phrase at you. STEPHANIE: Ooh, I'm ready. JOËL: Signal-to-noise ratio. STEPHANIE: Whoa, uh-huh. JOËL: So, how often is the feedback from your tool actually helpful, and how often is it just noise that you have to dismiss, or manually override, or things like that? At some point, the ratio becomes so much that you lose the signal in all the noise. And so, maybe you even, like, because you're always just ignoring the feedback from this tool, you accidentally start overriding things that would be genuinely helpful. And, at that point, you've got the worst of both worlds. So, sort of keeping track on what that ratio is, and there's not, like, a magic number. I'm not going to tell you, "Oh, this is an 80/20 principle. You need to have, you know, 80% of the time it's useful and only 20% of the time it's not useful." I don't have a number to give you, but keeping track on maybe, you know, is it more often than not useful? Is your team getting to the point where they're just ignoring feedback from this tool? And thinking in terms of that signal versus that noise, I think is useful—to go back to that word again, heuristic for managing whether a tool is still helpful. STEPHANIE: Yeah. And I would even go on to say that, you know, I always appreciate when people in leadership roles keep an eye on these things. And they're like, "Oh, I've been hearing that people are just totally numb to this tool [laughs]" or, you know, "There's no engagement on this. People are just ignoring those signals." Any developer impacted by this, it is valid to bring it up if you're getting frustrated by it or just finding yourself, you know, having all of these obstacles getting in the way of your development process. JOËL: Sometimes, this can be a symptom that you're mixing too many classes of problems together in one tool. So, maybe there are things that are, like, really dangerous to your product to go live with them. Maybe it's, you know, something like Brakeman where you're doing security checks, and you really, ideally, would not go to production with a failing security check. And then, you've got some random other style things in there, and you're just like, oh yeah, whatever, it's this tool because it's mostly style things but occasionally gives you a security problem. And because you ignore it all the time, now you accidentally go to production with a security problem. So, splitting that out and say, "Look, we've got blocking and unblocking because we recognize these two classes of problems can be a helpful solution to this problem." STEPHANIE: Joël, did you just apply an object-oriented design principle to an organizational system? [laughter] JOËL: I may be too much of a developer. STEPHANIE: Cool. Well, I really appreciate your input on this because, you know, I was just kind of mulling over, like, how I felt about these kinds of things that I encounter as a developer. And I am glad that we got to kind of talk about it. And I think it gives me a more expanded vocabulary to, you know, analyze or reflect when I encounter these things on different client organizations. JOËL: And every organization is different, right? Like, you've got to learn the culture, learn the different elements of that software. What are the things that are invariant? What are the things that are dangerous that we don't want to ship without? What are the things that we're doing just for consistency? What are things which are, like, these are culturally things that we'd like to do? There's all these levels, and it's a lot to pick up. STEPHANIE: Yeah. At the end of the day, I think what I really liked about the last thing you said was being able to identify the problem, like the class of problem, and applying the right tool for the right job. It helps me take a step back and perhaps even think of different solutions that we might not have thought about earlier because we had just gotten so used to the one way of enforcing or checking things like that. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Stephanie revisits the concept of "spiking"—a phase of exploration to determine the feasibility of a technical implementation or to address unknowns in feature requests—sharing her recent experiences with a legacy Rails application. Joël brings a different perspective by discussing his involvement with a client project that heavily utilizes the dry-rb suite of gems, highlighting the learning curve associated with adapting to new patterns and libraries. Joël used to be much more idealistic and has moved to be more pragmatic. Stephanie has moved the other way. So together, Stephanie and Joël engage in a philosophical discussion on being an idealistic versus a pragmatic programmer. They explore the concept of programming as a blend of science and art, where technical decisions are not only about solving problems but also about expressing ideas and building shared understandings within a team. Spike tasks episode (https://bikeshed.thoughtbot.com/414) dry-rb (https://dry-rb.org/) Working with Maybe talk (https://www.youtube.com/watch?v=43eM4kNbb6c) Problem solving with maybe (https://thoughtbot.com/blog/problem-solving-with-maybe) Programming as Theory Building (https://pablo.rauzy.name/dev/naur1985programming.pdf) The Pragmatic Programmer (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/) 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, a few weeks ago, we did an episode on spiking in response to a listener question. And I wanted to kind of revisit that topic for a little bit because I've been doing a lot of spiking on my client project. And for those who are not familiar, the way that I understand or define spikes is kind of as an exploration phase to figure out if a technical implementation might work. Or if you have a feature request with some unknowns, you can spend some time-boxed spiking to figure out what those unknowns might be. And I'm working on your typical legacy Rails application [laughs]. And I think one thing that we talked about last time was this idea of, at what point does spiking end up being just working on the feature [laughs]? And I think that's especially true in an older codebase, where you kind of have to go down a few rabbit holes, maybe, just to even find out if something will trip you up down the line. And the way I approached that this time around was just, like, identifying the constraints and putting a little flag there for myself. Like, these were rabbit holes that I could go down, but, you know, towards the initial beginning phase of doing the spiking, I decided not to. I just kind of bookmarked it for later. And once I had identified the main constraints, that was when I was like, okay, like, what kind of solutions can I come up with for these constraints? And that actually then helped me kind of decide which ones we're pursuing a little bit more to get, like, the information I needed to ultimately make a decision about whether this was worth doing, right? It kind of kept me...I'm thinking about, you know, when you are bowling with those safety guards [laughs], it keeps your ball from just rolling into the gutter. I think it helped with not going too deep into places that I may or may not be super fruitful while also, I think, giving me enough information to have a more realistic understanding of, like, what this work would entail. JOËL: Would you say that this approach that you're taking is inspired or maybe informed by the conversation we had on the episode? STEPHANIE: I was especially interested in avoiding the kind of binary of like, no, we can't do this because the system just, you know, isn't able to support it, or it's just too...it would be too much work. That was something I was really, like you said, kind of inspired by after that conversation because I wanted to avoid that trap a little bit. And I think another really helpful framing was the idea of, like, okay, what would need to be done in order to get us to a place where this could be possible? And that's why I think identifying those constraints was important because they're not constraints forever. Like, we could do something about them if we really wanted to, so kind of avoiding the, like, it's not possible, right? And saying like, "It could be. Here's all the things that we need to do in order to make it possible." But I think that helped shift the conversation, especially with stakeholders and stuff, to be a little bit more realistic and collaborative. So, Joël, what's new in your world? JOËL: So, I'm also on a new client project, and a thing that's been really interesting in this codebase is that they've been using the dry-rb suite of gems pretty heavily. And I've seen a lot about the suite of gems. I've read about them. Interestingly, this is kind of the first time that I've been on a codebase that sort of uses them as a main pattern in the app. So, there's been a bit of a learning curve there, and it's been really interesting. STEPHANIE: This is exciting to me because I know you have a lot of functional programming background, also, so it's kind of surprising that you're only now, you know, using something that explicit from functional languages in Ruby. And I'm curious: what's the learning curve, if not the paradigm? Like, what are you kind of encountering? JOËL: I think there's a little bit of just the translation. How do these gems sort of approach this? So, they have to do a couple of, like, clever Ruby things to make some of these features work. Some of these also will have different method names, so a lot of just familiarizing myself with the libraries. Like, oh, well, this thing that I'm used to having called a particular thing has a slightly different name here or maybe not having all of the utilities. I was like, oh, how do we traverse with this particular library? Then you have to, like, look it up. So, it's a lot of like, how do I do this thing I know how to do in, let's say, Elm? How do I translate that into Ruby? But then, also, some of the interplay of how that works in code that also does some very kind of imperative side effecty things also written by a team that is getting used to the pattern. And so, you'll sort of see things where people are pulling things in, but maybe you don't fully understand the deeper underlying approach that's meant to be used. STEPHANIE: Have you noticed any use cases where the dry-rb patterns really shine in your application? JOËL: A thing that's nice is that I think it really forces you to think about your edge cases in a way that sometimes Ruby developers play very fast and loose with "Yeah, whatever, it will never be nil." Push to production immediately start getting NoMethodError in your bug tracker. I never do this, by the way, but you know. STEPHANIE: [laughs]. JOËL: Speaking from a friend's experience [laughs]. STEPHANIE: Asking for a friend, yeah [laughs]. JOËL: I think a thing that I've sort of had to figure out sort of every time I deal with these patterns in different languages is just the importance of good composition and good separation. Because you're adding these sort of wrapper context around things, if you're constantly wrapping and unwrapping, you're like, check things inside, and then do the next thing, and then unwrap again and branch and check and do the next thing, that code becomes really clunky in a way that you just sort of expect to do if you're just writing code in regular Ruby with a nil. But it doesn't really work with a dry-rb maybe or a result. So, the pattern that I have found that works really well is to extract sort of every operation that can be, let's say, that could fail so that it would give you a result back. Extract that out into its own separate function that will construct a success or a failure, and then have your sort of main code that wants to then do a bunch of these things together. All it does is use some of the dry-rb helper methods to compose all of these together, whether that's just some sort of, like, do notation, or binding, or fmap, or something like that, which allows you to have sort of individual chunks that can fail, and then one sort of aggregator piece of code that just finds a way to combine all of them nicely. And that avoids you having to do all this repetition. STEPHANIE: Yeah, that makes a lot of sense. JOËL: It's a pattern, I think; I had to learn the hard way when I was working with Elm. Because if you're taking a potential nullable value and then you want to do things with it but then that potential operation is also nullable because the input was potentially null, and then that just sort of propagates all the way down the chain. So, my whole chain of functions now is doing checks for nullability. And in Ruby, I could just be like, no, I checked it in the first function. I can then just trust that it's not null down the chain. Elm doesn't do the like, trust me, bro. The compiler will force you to validate every time, and then the code just blows up, and it gets really painful. So, I had to start thinking about new models of thinking that would separate out code that actually needs to care and code that doesn't need to care about nullability. And I wrote an article about that. That turned into actually a conference talk as well. And these sort of ideas have served me really well at Elm. And I think these translate pretty well to dry-rb as well. That's something that I'm exploring, but the principles seem like they're not tied to a particular language. STEPHANIE: Yeah, and it's kind of cool that you experienced all of that in working with Elm, where a compiler was there to yell at you [laughs] and kind of forcing you to...I don't know if do the right thing is the right word, but kind of think in the way that it wants you to think. And I can see people who are coming from Ruby and starting to experiment with dry-rb maybe needing a bit of that since it's not built-in in the tooling, just in a recoder view or just in conversations among devs. JOËL: [inaudible 09:26] Beyond just the idea of wrapping your values and making sure you check them all the time, there are patterns that make that easier or more painful. And even in something like Elm, the compiler would yell at me would make sure I could not have a runtime error by forgetting to check for nullability. It did not prevent me from writing monstrosities of nested repeated conditionals checking if nil, if nil, if nil. That I had to figure out some sort of, like, higher-level patterns that play nicely with that kind of software. And I think these are things that people have to sort of encounter, feel the pain, feel the frustration, and then move into those better patterns after the fact. And sometimes that's not easy because it's not obvious why that's a valuable pattern to approach. STEPHANIE: Yeah, I agree completely. Speaking of following patterns and kind of arriving at maybe an ideal version of [chuckles], you know, what you'd like your code to do, you know, to build what you are looking to build [laughs]...this is my very poor attempt at a smooth transition that Joël [laughter] manages to be able to do [laughs] whenever we're trying to shift into the topic of the episode. Anyway, today, we were hoping to talk a little bit about this idea between being an idealistic programmer and a pragmatic programmer and the different journeys that we've each been on in arriving kind of how to balance the two. JOËL: Yeah, you know, I think neither of these are absolutes, right? It's a spectrum. You probably move around that spectrum from day to day, and then probably, like, more general trends over your career. But I'm curious, for you today, if you had to pick one of those labels, like, which sort of zone of the spectrum would you put yourself in? Do you think you're more idealistic or more pragmatic? STEPHANIE: I think I'm in a more of an idealistic zone right now. JOËL: Would you say you're kind of like middle trending idealistic or kind of, like, pretty far down the idealistic side? STEPHANIE: Middle trending idealistic. I like that way of describing it. I want to know where you are. And then I kind of wanted to try to take a step back and even define what that means for both of us. JOËL: Right, right. I think the way I'd probably describe myself is a recovering idealist. STEPHANIE: Oof. Yeah [laughs]. JOËL: I think there was a time where I was really idealistic. I really like knowing sort of underlying theory of software construction, broader patterns. By patterns here, I don't mean necessarily, like, you know, the Gang of Four, but just general sort of approaches that work well and using that to guide my work. But I've also been trending a lot more into the, like, pragmatic side of things in the past few years. STEPHANIE: So, could you kind of tell me a little bit about what does pragmatic mean for you and what does ideal mean for you? JOËL: So, I think the pragmatic side of me it's about delivering working software. If you're not shipping anything, you know, the most beautiful piece of art that you've created just warms your heart is useless. So, I think I'm sort of at the extreme end of pragmatism, right? It's all about shipping and shipping fast. And, in the end, that's generally the goal of software. On the more idealistic side, the sort of doing everything kind of perfect or by the book, or, you know, maybe in a way that brings you personal satisfaction, oftentimes, at the expense of shipping and vice versa. Sometimes shipping comes at the expense of writing absolutely terrible code, but, of course, you know, there's value in both. Shipping is what actually delivers value to your users, your company, yourself if you're using the software. But if you're not following patterns and things, you're often stuck in a really short-term thinking loop, where you are maybe delivering value today at the cost of being able to deliver value tomorrow or writing code that is unreadable or code that is difficult to collaborate on. So, more than just me shipping an individual feature, I've got to think about, while I'm working with a team, how can I help them be able to ship features or build on top of my work for tomorrow? So, that's sort of how I visualize the field. I'm curious what the words idealism and pragmatism mean to you. STEPHANIE: Yeah. I agree with you that pragmatism is, you know, this idea of delivering working software. And I think I have seen it very, you know, kind of condensed as, like, moving quickly, getting stuff out the door, basically, like, end result being, like, a thing that you can use, right? I think I've personally been reassessing that idea a lot because I'm kind of almost wondering like, well, what are we moving quickly for [laughs]? I sometimes have seen pragmatism just end there being like, okay, like, it's all about velocity. And then, I'm kind of stuck being like, well, if you write working software for, you know, completely the wrong thing, is that still pragmatic? I don't know. So, that's kind of where I'm at these days with–I'm feeling a little bit more suspect of pragmatism, at least wanting to make sure that, especially with the people that I'm working with day to day, that we're agreeing on what that means and what success means. And then, as for idealism, I think also, actually, I now have a little bit of duality in terms of how I understand that as well. One of them being, yes, definitely, like, by the book or, like, by the ideas that we've, you know, some very smart people [laughs] have figured out as, like, this is clean or good quality, or these are the patterns to, you know, make your code as, again, as clean, I don't know, kind of putting air quotes around that, as possible. And then, I actually like what you really said about code that warms your heart [laughs] that you feel, like, really moved by or, like, just excited about or inspired by because I think that can also be a little bit different from just following theories that other people have defined. The more I spend doing this stuff, the more I am convinced that writing software is actually a very creative practice. And that's something that I've, like, definitely had to balance with the pragmatism a bit more because there are days when it's just not coming [chuckles], you know, like, I just stare at a blank, new file. And I'm like, I can't even imagine what these classes would be because, like, that creative part of my brain just, like, isn't on that day. So, that's kind of where I'm sitting in terms of, like, what idealistic programming kind of seems to me. JOËL: There's definitely an element of programming that feels like self-expression, you know, there are parameters around that. And working with a team, you probably all sort of, like, move towards some average. But I would definitely say that there is some element of self-expression in coding. STEPHANIE: Yeah, 100%. Have you heard about this paper called Programming as Theory Building? JOËL: The name sounds vaguely familiar, but I can't place the main idea in my mind right now. STEPHANIE: It's, like, an academic-ish paper from the 80s. And I'll link to it in the show notes because I can't remember the author right now. But the idea is writing code is actually just one way of expressing a theory that we are building. In fact, that expression doesn't even....it's like, it's impossible for it to fully encapsulate everything that was involved in the building of the theory because every decision you make, you know, you decide what not to do as well, right? Like, all the things that you didn't encode in your application is still part of this theory, like stuff that you rejected in order to interpret and make abstract the things that you are translating from the quote, unquote "real world" into code. That really stuck with me because, in that sense, I love this idea that you can create your own little world, right? Like, you're developing it when you code. And that is something that gets lost a little bit when we're just focused on the pragmatic side of things. JOËL: Where things get tricky as well is that when you're working with a team, you're not just building your own little world. You're building a shared world with shared mental models, shared metaphors. That's where oftentimes it becomes important to make sure that the things that you are thinking about are expressed in a way that other people could read your code and then immediately pick up on what's happening. And that can be through things like documentation, code comments. It can also be through more rigorous data modeling. So, for example, I am a huge fan of value objects in general. I tend to not have raw numbers floating around in an app. I like to wrap them in some kind of class and say, "Hey, these numbers that are floating around they actually represent a thing," and I'll name that thing so that other people can get a sense that, oh, it is one of the moving parts of this app, and then here are the behaviors that we expect on it. And that is partly for sort of code correctness and things like that but also as a sort of way of communicating and a way of contributing to that shared reality that we're creating with the team in a way that if I just left a raw number, that would be almost, like, leaving something slightly undefined. Like, the number is there. It does a thing, but what it does is maybe a little bit more implied. I know in my mind that this is a dollar amount, and maybe there's even a comment above it that says, "Dollar amount." But it makes it a little bit harder for it to play in with everybody else's realities or view of the system than if it were its own object. STEPHANIE: Yeah, I like what you said about you're building a shared world with your fellow colleagues. And that helped explain to me why, as some people say, naming is the hardest part about building software because, yeah, like you said, even just saying you are wanting to make a method or class expressive. And we talked about how code is a way of expressing yourself. You could, like, name all your stuff in Wingdings [laughs], but we don't. I actually don't know if you could do that. But that was, for some reason, what I imagined. I was like, it's possible, and you could deliver software in complete gibberish [laughs]. JOËL: In theory, could you say that naming your variables as emoji is the most expressive way? Because now it's all emotions. STEPHANIE: A picture is worth a thousand words, as they say. JOËL: So, this variable is the frowny face, upside-down smile face. It doesn't get more expressive than that. STEPHANIE: At a former company, in our Slack workspace, I had a co-worker who loved to use the circus tent emoji to react to things. And, like, I'm convinced that no one really knew what it meant, but we also kind of knew what it meant. We were just like, oh yeah, that's the emoji that she uses to express amusement or, like, something a little bit ironic. And we all kind of figured it out [laughs] eventually. So, again, I do think it's possible. I bet someone has done, like, a creative experiment with writing an application in just emojis. This is now going to be some research I do after this episode [laughter]. JOËL: It is fun when you have, like, a teammate. You know they have the signature emoji that they respond to on things. STEPHANIE: Yep. Absolutely. So, you know, we kind of spent a little bit of time talking about idealism. I actually wanted to pull back to the idea of pragmatism because, in preparation for this episode, I also revisited my copy of The Pragmatic Programmer. Are you familiar with this book? Have you read it at all? JOËL: I have read it. It's been probably ten years. We did, I think, a book club at thoughtbot to go through the book. STEPHANIE: I was skimming the table of contents because I was curious about, again, that, like, definition of pragmatism. You and I had kind of talked about how it can be short-sighted. But what I was actually pretty impressed with, and I imagine this is why the book holds up, you know, after decades, is success for them also means being able to continue to deliver quality software. And that idea of continuity kind of implied, to me, that there was an aspect of, like, making sure the quality meets a certain threshold and, like, incorporating these theories and doing the best practices because they're thinking about success over time, right? Not just the success of this particular piece that you're delivering. JOËL: I would say most people in our industry are sort of balancing those two objectives, right? They're like, we want to have a decent velocity and ship things, but at the same time, we want to be able to keep delivering. We want a certain threshold of quality. In between those two objectives, there is a sea of trade-offs, and how you manage them are probably a little bit part of your personality as a developer and is probably also, to a certain extent, a function of your experience, learning sort of when to lean more into taking some shortcuts to ship faster and when to double down on certain practices that increase code quality, and what aspects of quality value more than others because not all forms of quote, unquote, "quality" are the same. I think a sort of source of danger, especially for newer developers, is you sort of start on almost, like, a hyper-pragmatic side of things because most people get into software because they want to build things. And the ultimate way to build is to ship, and then you sort of encounter problems where you realize, oh, this code is really clunky. It's harder and harder to ship. Let me learn some elements of code quality. Let's get better at my craft so that I can build software that has fewer bugs or that I can ship more consistently. And that's great. And then, you sort of run into some, like, broader sort of theories of programming: patterns, structures, things like that. And it becomes very easy to sort of blindly copy-paste that everywhere to the point where I think it's almost a bit of a meme, the, like, intermediate programmer who's read Clean Code or the Design Patterns book and is just now, like, applying these things blindly to every piece of code they encounter to the annoyance of the entire team. STEPHANIE: I think you just about described my trajectory [laughter], though hopefully, I was not so obnoxious about [laughs] it for my team having to deal with my, like, discovering [laughs] theories that have long been used. JOËL: I think we kind of all go through that journey to a certain extent, right? It's a little bit different for every one of us, but I think this is a journey that is really common for developers. STEPHANIE: Yeah. One thing I frequently think about a lot is how much I wished I had known some of that theory earlier. But I don't think I have an answer one way or another. It's like; I'm not sure if having that knowledge earlier really would have helped me because I've also definitely been in...I'm just thinking about, like, when I was in college in lectures trying to absorb theories that made no sense to me because I had no, like, practical experience to connect it to. It's almost, like, maybe there is, like, that perfect time [laughs] where it is the most valuable for what you're doing. And I don't know. I kind of believe that there is a way to bridge that gap. JOËL: I mean, now we're kind of getting into an element of pedagogy. Do you sort of teach the theory first, and then show how to apply it to problems? Or do you show problems and then introduce bits of theory to help people get unstuck and maybe then cap it off by like, oh, these, like, five different, like, techniques I showed you to, like, solve five different problems, turns out they all fit in some grand unified theory? And, like, here's how the five things you thought were five different techniques are actually the same technique viewed from five different perspectives. Let me blow your mind. STEPHANIE: That's a Joël approach [laughter] to teaching if I've ever heard one. JOËL: I'm a huge fan of that approach. Going back to some of the, like, the functional programming ideas, I think that's one that really connected for me. I struggled to learn things like monads, and functors, and things like that. And I think, in my mind, these two approaches is like the Haskell school of teaching and the Elm school of teaching. Haskell will sort of say, "Hey, let me teach you about this theory of monads and all these things, and then, we'll look at some ways where that can be applied practically." Whereas Elm will say, "No, you don't need to know about this. Let's look at some practical problems. Oh, you've got null values you need to check. Here's how you can, like, handle nullability in a safe way. Oh, you've got a bunch of HTTP requests that might resolve in random order, and you want to, like, deal with them when they all come back. Here's some tips on how you can do that." And then, you have three or four things, and then, eventually, it just sort of lets you say, "Wait a minute, all of these problems are sort of all the same, and it turns out they all fit in some unified theory." And then, the light bulb goes off, and you're like, "Ooh, so now when I'm dealing with unknown blobs of Jason trying to parse data out of them, I'll bet I can use the same techniques I used for chaining HTTP requests to dig multiple dependent pieces of JSON." STEPHANIE: Yeah. And that's so satisfying, right? It really is kind of leveling up in that Galaxy Brain meme sort of way. JOËL: Yeah. And that's maybe to a certain extent even a value of idealism because if you build your system in such a way that it follows some of these patterns, then insights and intuitions that people have in one part of your code can then carry to other parts of your code, and that's incredibly powerful. STEPHANIE: Yeah. And I almost wonder because you also mentioned kind of where you end up on the spectrum is a function of your experience. I wonder if us, you know, being consultants and seeing patterns across many applications also kind of contributes to the striving for idealism [laughs]. JOËL: It's kind of both, right? Because there's very high incentive to ship pretty rapidly, especially if you're on a shorter engagement or if you're on a project that has a shorter timescale. But also, yes, because you've seen so many projects, you've seen how things can go wrong. Also, you've seen the same problem from 20 different perspectives that are all slightly different. And so, some of those broader patterns can start emerging in your head. STEPHANIE: Yeah, honestly, I think that's kind of the work that I enjoy the most in consulting because a lot of clients bring us on when they're like, "Hey, like, we've reached a point where our velocity has slowed down. Like, can you help us unstick our developers?" And that's actually when I've found that leaning on the theories and maybe a little bit of idealism is actually really useful because I'm kind of providing those tools to developers at this time when they need it. That's kind of why I have been saying trending idealism because I have found that particularly useful at work. JOËL: There's an element here of, like, looking at a bunch of different use cases and then finding some sort of unifying model or theory. And that's a word that I think programmers have a love-hate relationship with: Abstraction. I don't know about you, but designing abstractions is a lot of fun for me. I love designing abstractions. I have always loved designing abstractions. It's not always the best use of my time, and it's not always the best thing for a codebase. STEPHANIE: Ooh, okay, okay. This was a good transition. I hear you that, like, yeah, love-hate relationship. It's hard. That's kind of where I've ended up. It's really hard. And I think it's because it requires that creative thinking. JOËL: It requires that creative thinking. And then also, like, it requires you to sort of see more broadly, a more broad picture. What are the things that are connected, the things that are disconnected, even though they seem related? And, like, being able to sort of slice those similarities from each other. STEPHANIE: Yeah. I agree. And the interesting part is that, like, a lot of the time you just don't know yet. And you kind of have to come back to reality and admit that you don't know yet, you know, got to come back to earth, take a look around, and, yeah, you can go through the thought exercise of thinking [laughs] about all of the possibilities, and I imagine you could do that forever [laughs]. JOËL: I mean, that's why we have heuristics like the rule of three that says, "Don't abstract something out or attempt to DRY code until you've seen three use cases of it." So, maybe leave a little bit of duplication or a little bit of maybe not perfectly factored code until you have a couple of more examples. And the sort of real picture starts emerging a little bit more. STEPHANIE: So, I think we are kind of at this topic already, but was there a moment or was there something that kind of helped you realize, like, oh, I can't be in that space of imagining abstractions [laughs] forever when I have to deliver software? Like, what changed for you to be the, as you said yourself, recovering idealist and having to maybe employ some more pragmatic heuristics? JOËL: And I think, for me, it's partly being a consultant and being in a lot of projects and having that pressure to work with deadlines and sort of not having an infinite canvas to paint with, having to sort of fit some of my grand ideas into the reality of, we've got a week or two weeks to get this thing done, and also working with a team, and some ideas don't work well with every team. Every team is kind of at a different place. And abstractions sort of only serve you as well as they are useful to not only you but the team at large. So, if a team is not comfortable with a set of abstractions, or it's sort of, like, too far down a path, then that can be really challenging. And that's where something like the dry-rb set of gems, which has some really fun abstractions like a mental model for doing things, depending on the team, that can be a really heavy lift. And so, as much as I like those patterns, I might think long and hard before I try to push this on a whole team. STEPHANIE: Yeah, I kind of had to navigate a situation like that recently, where I was doing a code review, and I had left some suggestions about refactoring to encapsulate some responsibilities better. And then, I was like, oh, and then I noticed another thing that we could do to make that easier. And it, you know, definitely can start to spiral. And the author, you know, kind of responded to me and said, "Hey, like, I really appreciate these comments, but we are a bit tight on deadline for this project. So, is it okay if I, like, revisit this when we've delivered it?" And, you know, I was just like, "Yeah, it's totally up to you." At the end of the day, I want whoever's authoring this code to have, like, full agency about how they want to move forward. And it was really helpful for me to get that context of, like, oh, they're a bit tight on the deadline because then I can start to meet them where they're at. And maybe I can give some suggestions for moving towards that ideal state, but ones that are lower left, and that is still better than nothing. JOËL: That sounds awfully pragmatic. STEPHANIE: [laughs] JOËL: Moving in a positive direction, we're getting halfway. It's better than nothing. That's very pragmatic. STEPHANIE: Hmm. Wow. But it's pragmatically moving towards idealism. JOËL: [laughs] STEPHANIE: If that is even possible [laughs]. JOËL: Uh-huh. STEPHANIE: That's maybe the book that I'm going to write, not The Pragmatic Programmer, but The Pragmatically Idealistic Programmer [laughs]. JOËL: The Pragmatic Idealist. STEPHANIE: Ooh, yeah, I like that. Okay. Watch out for that book coming 2030 [laughter], written by me and Joël. JOËL: So, I think you brought up a really interesting point, which is the idea of pragmatism versus idealism when it comes to code review. Do you find that you think about these ideas differently when reviewing somebody else's code versus when you write your own? STEPHANIE: Oooh, yeah. I'm not sure exactly why, but definitely, when I'm reviewing someone else's code, I'm already in the headspace of, you know, I have some separation, right? Like, I'm not in the mode of thinking very hard [laughs] about what I'm creating. I'm just, like, in the editing kind of phase. And then, I can actually pull more from different theories and ideas, and I find that actually quite easier. When I'm writing my own code, it's just whatever comes out, right? And then, hopefully, I have the time to revisit it and give it a scan, and then start to integrate the, like, idealistic theories and the patterns that I would like to be using. But it definitely...for patterns that I feel a lot more confident about or more familiar with, they just come out mostly kind of oriented in that way if I have the time, or sometimes I will make the time, you know. I'll just say, "It's not done yet," because I know it can be better. I think that could be another, like, pragmatically idealist way of handling that. JOËL: [laughs] STEPHANIE: Right? It's just telling people, "I'm not done." [laughs] It's not done until I do at least give it an attempt. JOËL: So, it's kind of a two-phase thing when you're writing your own code, whereas it's only a single phase when you're reviewing somebody else's. STEPHANIE: Yeah. Yeah. But, like I said earlier, it's like, I also really believe that I don't want to impose any of my ideas [laughs] onto others. I really believe that people have to arrive at it on their own. So, it used to bother me a little bit more when I was just like, oh, but this way is better [laughs]. When people wouldn't get on board, I would be sad about it. But as long as I know that I, like, left that comment, then I can give myself a pat on the back for trying to move towards that ideal state. What about you [laughs]? JOËL: I think this is probably also where I'm, like, now a recovering idealist. There was a time where I would leave a ton of comments on someone's PR. I almost had a view of like, how can I help you get your PR to be the best it can possibly be? And sometimes, if you start with something that's very rough around the edges, you're leaving a lot of comments. And I've been that guy who's left 50 comments on a PR. In retrospect, I think that was not being a good teammate. STEPHANIE: Hmm. JOËL: So, I think maybe my mental model or my, like, goal for PR review has changed a little bit. It's less about how can I help you make your code the best it can possibly be? And a how can I help you get your code to mergeable? And it's possible that mergeable means best that it can possibly be, but that's usually not the case. So, I'm going to give you some feedback: some things that confuse me, maybe raise one or two patterns that are existing in the app that maybe you weren't aware of that you should maybe consider applying. Maybe I'll raise a couple of ideas that are new, but that apply here. And those might just be a, "Hey, let's just think about this. Maybe we don't want to do this in this PR, but maybe we want to look at them at some point. Or we should be thinking about this in a sort of rule of three situation. If we see this come up another time, maybe consider introducing a strategy pattern here, or maybe consider making this a value object, or separating these side effects from these pure behavior." But it's more of a dialogue about how can I help you get your PR to the point where it is mergeable? STEPHANIE: Yeah. Another thing I thought about just now is both are meaningful or, like, both can provide meaning in different ways, and people ascribe different amounts of meaning to both; where I had worked with someone, a client developer before, who was not super interested in doing any kind of refactoring or, like, any, you know, second passes for quality. Because, for him, like, he just wanted to ship, right? That was where he found meaning in his work. Whereas that actually made my work feel a lot more meaningless [chuckles] because I'm like, well, if we're just kind of hands on a keyboard, like robots shipping code, I don't know, that doesn't feel particularly motivating for me. You know, I do want to employ some of that craft a little bit more. JOËL: And, I guess, yeah, idealism versus pragmatism is also...it's a personal individual thing. There's an element where it's a team decision, or at least a sense of, like, how much quality do we need at this point in the life cycle of the project? And what are the areas where we particularly want to emphasize quality? What are our quality standards? And that's, to a certain extent, consensus among the team that it's individual members. And it's also coming from team leadership. STEPHANIE: Yeah. Yeah, exactly. I mentioned that, you know, just to, I think, shed a little bit of light that it's usually not personal, right [laughs]? There's that part of understanding that is really important to, yeah, like, keep building this shared world of writing software, and, hopefully, it should be meaningful for all of us. JOËL: I think a few takeaways that I have would be, one, the value of, like, theory and idealism. These things help you to become a better developer. They help you to spot patterns. It's probably good to sort of have in the background always be learning some new thing, whether that's learning a new set of patterns, or learning some mental models, thinking about, oh, the difference between side effects and pure code, learning about particular ways of structuring code. These are all things that are good to have in your back pocket to be able to apply to the code that you're doing, even if it's a sort of after-the-fact, hey, I've done a similar task three different times. Is there a broader principle? But then, also, take the time to really make sure that you're focusing on shipping code, and maybe that's learning to work in smaller chunks, working iteratively, learning to scope your work well. Because, in the end, delivering value is a thing that is something that we could all probably benefit from doing more of. And then, finally, taking some time to self-reflect, a little bit of self-awareness in this area. What are the aspects of pragmatism and idealism that you find personally meaningful? What are the elements that you think bring value to your work, to your team? And let that sort of guide you on your next code writing or PR review. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Joël discusses the challenges he encountered while optimizing slow SQL queries in a non-Rails application. Stephanie shares her experience with canary deploys in a Rails upgrade. Together, Stephanie and Joël address a listener's question about replacing the wkhtml2pdf tool, which is no longer maintained. The episode's main topic revolves around the concept of multidimensional numbers and their applications in software development. Joël introduces the idea of treating objects containing multiple numbers as single entities, using the example of 2D points in space to illustrate how custom classes can define mathematical operations like addition and subtraction for complex data types. They explore how this approach can simplify operations on data structures, such as inventories of T-shirt sizes, by treating them as mathematical objects. EXPLAIN ANALYZE visualizer (https://explain.dalibo.com/) Canary in a coal mine (https://en.wikipedia.org/wiki/Sentinel_species#Canaries) Episode 413: Developer Tales of Package Management (https://bikeshed.thoughtbot.com/413) Docs for media-specific CSS (https://developer.mozilla.org/en-US/docs/Web/CSS/@media) Episode 386: Value Objects Revisited: The Tally Edition (https://bikeshed.thoughtbot.com/386) Money gem (https://github.com/RubyMoney/money) 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: I've recently been trying to do some performance enhancements to some very slow queries. This isn't a Rails app, so we're sort of combining together a bunch of different scopes. And the way they're composing together is turning out to be really slow. And I've reached for a tool that is just really fun. It's a visualizer for SQL query plans. You can put the SQL keywords in front of a query: 'EXPLAIN ANALYZE,' and it will then output a query plan, sort of how it's going to attempt to do the work. And that might be like, oh, we're going to use this index on this table to join on this other thing, and then we're going to...maybe this is a table that we think we're going to do a sequential scan through and, you know, it builds out a whole thing. It's a big block of text, and it's kind of intimidating to look at. So, there are a few websites out there that will do this. You just paste a query plan in, and they will build you a nice, little visualization, almost like a tree of, like, tasks to be done. Oftentimes, they'll also annotate it with metadata that they pulled from the query plan. So, oh, this particular node is the really expensive one because we're doing a sequential scan of this table that has 15 million rows in it. And so, it's really useful to then sort of pinpoint what are the areas that you could optimize. STEPHANIE: Nice. I have known that you could do that EXPLAIN ANALYZE on a SQL query, but I've never had to do it before. Is this your first time, or is it just your first time using the visualizer? JOËL: I've played around with EXPLAIN ANALYZE a little bit before. Pro tip: In Rails, if you've got a scope, you can just chain dot explain on the end, and instead of running the query, it will run the EXPLAIN version of it and return the query plan. So, you don't need to, like, turn into SQL then manually run it in your database system to get the EXPLAIN. You can just tack a dot explain on there to get the query plan. It's still kind of intimidating, especially if you've got a really complex query that's...this thing might be 50 lines long of EXPLAIN with all this indentation and other stuff. So, putting it into a sort of online visualizer was really helpful for the work that I was doing. So, it was my first time using an online visualizer. There are a few out there. I'll link to the one that I used in the show notes. But I would do that again, would recommend. STEPHANIE: Nice. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, I actually just stepped away from being in the middle of doing a Rails upgrade [chuckles] and releasing it to production just a few minutes before getting on to record with you on this podcast. And the reason I was able to do that, you know, without feeling like I had to just monitor to see how it was going is because I'm on a project where the client is using canary deploys. And I was so pleasantly surprised by how easy it made this experience where we had decided to send the canary release earlier this morning. And the way that they have it set up is that the canary goes to 10% of traffic. 10% of the users were on Rails 7 for their sessions. And we saw a couple of errors in our error monitoring service. And we are like, "Okay, like, let's take a look at this, see what's going on." And it turns out it was not too big of a deal because it had to do with, like, a specific page. And, for the most part, if a user did encounter this error, they probably wouldn't again after refreshing because they had, like, a 90% chance [chuckles] of being directed to the previous version where everything is working. And we were kind of making that trade-off of like, oh, we could hotfix this right now on the canary release. But then, as we were starting to debug a little bit, it was a bit hairier than we expected originally. And so, you know, I said, "I have to hop on to go record The Bike Shed. So, why don't we just take this canary down just for the time being to take that time pressure off? And it's Friday, so we're heading into the weekend. And maybe we can revisit the issue with some fresh eyes." So, I'm feeling really good, actually. And I'm glad that we were able to do something that seems scary, but there were guardrails in place to make it a lot more chill. JOËL: Yay for the ability to roll back. You used the term canary release. That's not one that I'm familiar with. Can you explain what a canary release is? STEPHANIE: Oh yeah. Have you heard of the phrase 'Canary in the coal mine'? JOËL: I have. STEPHANIE: Okay. So, I believe it's the same idea where you are, in this case, releasing a potentially risky change, but you don't want to immediately make it available to, like, all of your users. And so, you send this change to, like, a small reach, I suppose, and give it a little bit of a test and see [chuckles] what comes back. And that can help inform you of any issues or risks that might happen before kind of committing to deploying a potentially risky change with a bigger impact. JOËL: Is this handled with something like a feature flag framework? Or is this, like, at an infrastructure level where you're just like, "Hey, we've got the canary image in, like, one container on one server, and then we'll redirect 10% of traffic to that to be served by that one and the other 90% to be served by the old container or something like that"? STEPHANIE: Yeah, in this case, it was at the infrastructure level. And I have also seen something similar at a feature flag level, too, where you're able to have some more granularity around what percent of users are seeing a feature. But I think with something like a Rails upgrade, it was nice to be able to have that at that infrastructure level. It's not necessarily, like, a particular page or feature to show or not show. JOËL: Yeah, I think you would probably want that at a higher level when you're changing over the entire app. Is this something that you had to custom-build yourself or something that just sort of came out of the box with some of the infrastructure tools you're using? STEPHANIE: It came out of the box, actually. I just joined this client project this week and was very delighted to see just some really great deployment infrastructure and getting to meet the DevOps engineers, too, who built it. And they're really proud of it. They kind of walked us through our first release earlier this week. And he was telling me, the DevOps engineer, that this was actually his favorite part of the job, is walking people through their first release and being their buddy while they do it. Because I think he gets to also see users interact with the tool that he built, and he had a lot of pride in that, so it was a very delightful experience. JOËL: That's so wonderful. I've been on so many projects where the sort of infrastructure side of things is not the team's strong point, and releasing can be really scary. And it's great to hear the opposite of that. We recently received a question for Stephanie based on an earlier episode. So, the question asks, "In episode 413, Stephanie discussed a recent issue she encountered with wkhtml2pdf. The episode turned into a deeper discussion about package management, but I don't think it ever cycled back to the conclusion. I'm curious: how did Stephanie solve this dilemma? We're facing the same issue on a project that my team maintains. It's an old codebase, and there are bits of old code that use wkhtml2pdf to generate print views of our data in our application. The situation is fairly dire. wkhtml2pdf is no longer maintained. In fact, it won't even be available to install from our operating system's package repositories in June. We're on FreeBSD, but I assume the same will be eventually true for other operating systems. And so, unless you want to maintain some build step to check out and compile the source code for an application that will no longer receive security updates, just living with it isn't really an option. There are three options we're considering. One, eliminate the dependency entirely. Based on user feedback, it sounds like our old developers were using this library to generate PDFs when what users really wanted was an easy way to print. So, instead of downloading a PDF, just ensure the screen has a good print style sheet and register an onload handler to call window dot print. We're thinking we could implement this as an A/B test to the feature to test this theory. Or two, replace wkhtml2pdf with a call to Headless Chrome and use that to generate the PDF. Or, three, replace wkhtml2pdf with a language-level package. For us, that might be the dompdf library available via Composer because we're a PHP shop." Yeah, a lot to unpack here. Any high-level thoughts, Stephanie? STEPHANIE: My first thought while I was listening to you read that question is that wkhtml2pdf is such a mouthful [laughs]. And I was impressed how you managed to say it at least, like, five times. JOËL: So, I try to say that five times fast. STEPHANIE: And then, my second high-level thought was, I'm so sorry to Brian, our listener who wrote in, because I did not really solve this dilemma [chuckles] for my project and team. I kind of kicked the can down the road, and that's because this was during a support and maintenance rotation that I've talked a little bit about before on the show. I was only working on this project for about a week. And what we thought was a small bug to figure out why PDFs were a little bit broken turned out, as you mentioned, to be this kind of big, dire dilemma where I did not feel like I had enough information to make a good call about what to do. So, I kind of just shared my findings that, like, hey, there is kind of a risk and hoping that someone else [laughs] would be able to make a better determination. But I really was struck by the options that you were considering because it was actually a bit of a similar situation to the bug I was sharing where the PDF that was being generated that was slightly broken. I don't think it was, like, super valuable to our users that it be in the form of a PDF. It really was just a way for them to print something to have on handy as a reference from, you know, some data that was generated from the app. So, yeah, based on what you're sharing, I feel really excited about the first one. Joël, I'm sure you have some opinions about this as well. JOËL: I love sort of the bigger picture thinking that Brian is doing here, sort of stepping back and being like, wait, why do we even need PDF here, and how are our customers using it? I think those are the really good questions to ask before sinking a ton of time into coming up with something that might be, like, a bit of a technical wonder. Like, hey, we managed to, like, do this PDF generation thing that we had to, like, cobble together so many other things. And it's so cool technically, but does it actually solve the underlying problem? So, shout out to Brian for thinking about it in those terms. I love that. Second cool thing that I wanted to shout out, because I think this is a feature of browsers that not many people are aware of; you can have multiple style sheets for your page, and you can tag them to be for different media. So, you can have a style sheet that only gets applied when you print versus when you display on screen. And there are a couple of others. I don't remember exactly what they are. I'll link to the docs in the show notes. But taking advantage of this, like, this is old technology but making that available and saying, "Yeah, we'll make it so that it's nice when you print, and we'll maybe even, you know, a link or a button with JavaScript so that you could just Command-P or Control-P to print. But we'll have a button in there as well that will allow you to print to PDF," and that solves your problem right there. STEPHANIE: Yeah, that's really cool. I didn't know that about being able to tag style sheets for different media types. That's really fascinating. And I like that, yeah, we're just eliminating this dependency on something, like, potentially really complex with a, hopefully, kind of elegant and modern solution, maybe. JOËL: And your browser is already able to do so many of these things. Why do we sort of try to recreate it? Printing is a thing browsers have been able to do for a long time. Printing to PDF is a thing that you can do for a long time. I will sometimes use that on sites where I need to, let's say I'm purchasing something, and I need some sort of receipt to expense, but they won't give me a download, a PDF download that I can send to the accounting team, so I will print to PDF the, like, HTML view. And that works just fine. It's kind of a workaround hack. Sometimes, it doesn't work well because the HTML page is just not well set up to, like, show up on a PDF page. You get some, like, weird, like, pagination issues or things like that. But, you know, just a little bit of thought for a print style sheet, especially for something you know that people are likely going to want to print or to save to PDF, that's a nice touch. STEPHANIE: Yeah. So, good luck, Brian, and let us know how this goes and any outcomes you find successful. So, for today's longer topic, I was excited because I saw, Joël, you dropped something in our topic backlog: Multidimensional Numbers. I'm curious what prompted this idea and what you wanted to say about it. JOËL: We did an episode a while back where we talked about value objects, wrapping numbers, wrapping collections. This is Episode 386, and we were talking about tallying, specifically working with collections of T-shirt sizes and doing math on these sort of objects that might contain multiple numbers. And a sort of sidebar from that that we didn't really get into is the idea that objects that contain sort of multiple numbers can be treated as a number themselves. And I think a great example of this is something like a point in two-dimensional space. It's got an x coordinate, a y coordinate. It's two numbers, but you can treat sort of the combination of the two of them together as a single number. There's a whole set of coordinate math that you can do to do things like add coordinates together, subtract them, find the distance between them. There's a whole field of vector math that we can do on those. And I think learning to recognize that numbers are not just instances of the integer or the float class but that there could be these more complex things that are also numbers is maybe an important realization and something that, as developers, if we think of these sort of more complex values as numbers, or at least mathematical objects, then that will help us write better code. STEPHANIE: Cool. Yeah. When you were first talking about 2D points, I was thinking about if I have experience working with that before or, like, having to build something really heavily based off of, like, a canvas or, you know, a coordinate system. And I couldn't think of any really good examples until I thought about, like, geographic locations. JOËL: Oh yeah, like a latitude, longitude. STEPHANIE: Yeah, exactly. Like, that is a lot more common, I think, for various types of just, like, production applications than 2D points if you're not working on, like, a video game or something like that, I think. JOËL: Right, right. I think you're much more likely to be working with 2D points on some more sort of front-end-heavy application. I was talking with someone this week about managing a seat map for concerts and events like that and sort of creating a seat map and have it be really interactive, and you can, like, click on seats and things like that. And depending on the level of libraries you're using to build that, you may have to do a lot of 2D math to make it all come together. STEPHANIE: Yeah. So, I would love to get into, you know, maybe we've realized, okay, we have some kind of compound number. What are some good reasons for using them differently than you would a primitive? JOËL: So, you mentioned primitives, and I think this is where maybe I'm developing a reputation about, like, always wanting value objects for everything. But it would be really easy, let's say, for an xy point to be just an array of two numbers or maybe even a hash with an x key and a y key. What's tricky about that is that then you don't have the ability to do math on them. Arrays do define the plus operator, but they don't do what you want them to do with points. It's the set union. So, adding two points would not at all do what you want, or subtracting two points. So, instead, if you have a custom 2D point class and you can define plus and minus on there to do the right thing, now they're not pairs of numbers, two values; they're a single value, and you can treat them as if they are just a single number. STEPHANIE: You mentioned that arrays don't do the right thing when you try to add them up. What is the right thing that you're thinking of then? JOËL: It probably depends a little bit on the type of object you're working with. So, with 2D points, you're probably trying to do vector addition where you're effectively saying almost, like, "Shift this point in 2D space by the amount of this other point." Or if you're doing a subtraction, you might even be asking, like, "What is the distance between these two points?" Euclidean distance, I think, is the technical term for this. There's also a couple of different ways you can multiply values. You can multiply a 2D point by just a sort of, not by another point, but by just an integer. That's called scaling. So, you're just like, oh, take this point in 2D space, but make it bigger, make it five times bigger or five times further from the origin. Or you can do some stuff with other points. But what you don't want to do is turn this into, if you're starting with arrays, you don't want to turn this into an array of four points. When you add two points in 2D space, you're not trying to create a point in 4D space. STEPHANIE: Whoa, I mean [laughs], maybe you're not. JOËL: You could but -- [laughter] STEPHANIE: Yeah. While you were saying that, I guess that is what is really cool about wrapping, encapsulating them in objects is that you get to decide what that means for you and your application, and -- JOËL: Yeah. Well, plus can mean different things, right? STEPHANIE: Yeah. JOËL: On arrays, plus means combining two arrays together. On integers, it means you do integer math. And on points, it might be vector addition. STEPHANIE: Are there any other arithmetic operators you can think of that would be useful to implement if you were trying to create some functionality on a point? JOËL: That's a good question because I think realizing the inverse of that is also a really powerful thing. Just because you create a sort of new mathematical object, a point in 2D space, doesn't mean that necessarily every arithmetic operator makes sense on it. Does it make sense to divide a point by another point? Maybe not. And so, instead of going with the mindset of, oh, a point is a mathematical object, I now need to implement all of arithmetic on this, instead, think in terms of your domain. What are the operations that make sense? What are the operations you need for this point? And, you know, maybe the answer is look up what are the common sort of vector math operations and implement those on your 2D point. Some of them will map to arithmetic operators like plus and minus, and then some of them might just be some sort of custom method where maybe you say, "Oh, I want the Euclidean distance between these two points." That's just a thing. Maybe it's just a named instance method on there. But yeah, don't feel like you need to implement all of the math operators because that's a mistake that I have made and then have ended up, like, implementing nonsensical things. STEPHANIE: [laughs] Creating your own math. JOËL: Yes, creating my own math. I've done this even on where I've done value objects to wrap single values. I was doing a class to represent currency, and I was like, well, clearly, you need, like, methods to, like, add or subtract your currency, and that's another thing. If you have, let's say, a plus method, now you can plug it into, let's say, reduce plus. And you can just sum a list of these currency objects and get back a new currency. It's not even going to give you back an integer. You just get a sort of new currency object that is the sum of all the other ones, and that's really nice. STEPHANIE: Yeah, that's really cool. It reminds me of all the magic of enumerable that you had talked about in a previous conference talk, where, you know, you just get so much out of implementing those basic operators that, like, kind of scales in handiness. JOËL: Yes. Turns out Ruby is actually a pretty nice system. If you have objects that respond to some common methods and you plug them into enumerable, and it just all kind of works. STEPHANIE: So, one thing you had said earlier that I've felt kind of excited about and wanted to highlight was you mentioned all the different ways that you could represent a 2D point with more primitive data stores, so, you know, an array of two integers, a hash with xy keys. It got me thinking about how, yeah, like, maybe if your system has to talk to another system and you're importing data or exporting data, it might eventually need to take those forms. But what is cool about having an encapsulated object in your application is you can kind of control those boundaries a little bit and have more confidence in terms of the data types that you're using within your system by having various ways to construct that, like, domain object, even if the data coming in is in a different shape. JOËL: And I think that you're hitting on one of the real beauties of object-oriented programming, where the sort of users of your object don't need to know about the internal representation. Maybe you store an array internally. Maybe it's two separate instance variables. Maybe it's something else entirely. But all that the users of your, let's say, 2D point object really need to care about is, hey, the constructor wants values in this shape, and then I can call these domain methods on it, and then the rest just sort of happens. It's an implementation detail. It doesn't matter. And you alluded, I think, to the idea that you can sort of create multiple constructors. You called them constructors. I tend to call them that as well. But they're really just class methods that will kind of, like, add some sugar on top of the constructor. So, you might have, like, a from array pair or from hash or something like that that allows you to maybe do a little bit of massaging of the data before you pass it into your constructor that might want some underlying form. And I think that's a pattern that's really nice. STEPHANIE: Yeah, I agree. JOËL: Something that can be interesting there, too, is that mathematically, there are multiple ways you can think of a 2D point. An xy coordinate pair is a common one, but another sort of system for representing a point in 2D space is called the polar coordinate system. So, you have some sort of, like, origin point. You're 0,0. And then, instead of saying so many to the left and so many up from that origin point, you give an angle and a distance, and that's where your point is. So, an angle and distance point, I think, you know, theta and magnitude are the fancy terms for this. You could, instead of creating a separate, like, oh, I have a polar coordinate point and a Cartesian coordinate point, and those are separate things, you can say, no, I just have a point in 2D space. They can be constructed from either an xy coordinate pair or a magnitude angle pair. Internally, maybe you convert one to the other for internal representation because it makes the math easier or whatever. Your users never need to know that. They just pass in the values that they want, use the constructor that is most convenient for them, and it might be both. Maybe some parts of the app require polar coordinates; some require Cartesian coordinates. You could even construct one of each, and now you can do math with each other because they're just instances of the same class. STEPHANIE: Whoa. Yeah, I was trying to think about transforming between the two types as well. It's all possible [laughs]. JOËL: Yes. Because you could have reader-type methods on your object that say, oh, for this point, give me its x coordinate; give me its y coordinate. Give me its distance from the origin. Give me its angle from the origin. And those are all questions you can ask that object, and it can calculate them. And you don't need to care what its internal representation is to be able to get all four of those. So, we've been talking about a lot of these sort of composite numbers, not composite numbers, that's a separate mathematical thing, but numbers that are composed of sort of multiple sub-numbers. And what about situations where you have two things, and one of them is not a number? I'm thinking of all sorts of units of measure. So, I don't just have three. I have three, maybe...and we were talking about currency earlier, so maybe three U.S. dollars. Or I don't just have five; I have five, you know, let's say, meters of distance. Would you consider something like that to be one of these compound number things? STEPHANIE: Right. I think I was–when we were originally talking about this, conflating the two. But I realized that, you know, just because we're adding context to a number and potentially packaging it as a value object, it's still different from what we're talking about today where, you know, there's multiple components to the number that are integral or required for it to mean what we intended to mean, if that makes sense. JOËL: Yeah. STEPHANIE: So yeah, I guess we did want to kind of make a distinction between value objects that while the additional context is important and you can implement a lot of different functionality based on what it represents, at the end of the day, it only kind of has one magnitude or, like, one integer to kind of encapsulate it represented as a number. Does that sound right? JOËL: Yeah. You did throw out the words encapsulation and value object. So, in a situation maybe where I have three US dollars, would you create some kind of custom object to wrap that? Or is that a situation where you'd be more comfortable using some kind of primitive? Like, I don't know, maybe an array pair of three and the symbol USD or something like that. STEPHANIE: Oh, I would definitely not do that [laughter]. Yeah. Like I, you know, for the most part, I think I've seen that as a currency object, and that expands the world of what we can do with it, converting into a lot of different other currencies. And yeah, just making sure those things don't get divorced from each other because that context is what gives it meaning. But when it comes to our compound numbers, it's like, without all of the components, it doesn't make sense, or it doesn't even represent the same, like, numerical value that we were trying to convey. JOËL: Right. You need both, or, you know, it could be more than two. It could be three, four, or five numbers together to mean something. You mentioned conversions, which I think is something that's also interesting because a lot of units of measure have sort of multiple ways of measuring, and you often want to convert between them. And maybe that's another case where encapsulation is really nice where, you know, maybe you have a distance object. And you have five meters, and you put that into your distance object, but then somebody wants it in feet somewhere else or in centimeters, or something like that. And it can just do all the conversion math safely inside that object, and the user doesn't have to worry about it. STEPHANIE: Right. This is maybe a bit of a tangent, but as a Canadian living in the U.S., I don't know [laughs] if you have any opinions about converting meters and feet. JOËL: The one I actually do the most often is converting Celsius to Fahrenheit and vice versa. You know, I've been here, what, 11 years now? I don't have a great intuition for Fahrenheit temperatures. So, I'm converting in my head just [laughs] on a daily basis. STEPHANIE: Yeah, that makes sense. Conversions: they're important. They help out our friends who [laughs] are on different systems of measurement. JOËL: There's a classic story that I love about unit conversions. I think it's one of the NASA Mars missions. STEPHANIE: Oh yeah. JOËL: You've heard of this one. It was trying to land on Mars, and it burned up in the atmosphere because two different teams had been building different components and used different unit systems, both according to spec for their own module. But then, when the modules try to talk to each other, they're sending over numbers in meters instead of feet or something like that. And it just caused [laughs] this, like, multi-year, multi-billion dollar project to just burn up. STEPHANIE: That's right. So, lesson of the day is don't do that. I can think of another example where there might be a little bit of misconceptions in terms of how to represent it. And I'm thinking about time and when that has been represented in multiple parts, such as in hours and, minutes and seconds. Do you have any initial impressions about a piece of data like that? JOËL: So, that's really interesting, right? Because, at first glance, it looks like, oh, it's, like, a triplet of hour, minute, seconds. It's sort of another one of these sort of compound numbers, and I guess you could implement it that way. But in reality, you're tracking a single quantity, the amount of time elapsed, and that can be represented with a single number. So, if you're representing, let's say, time of day, what would show up on your clock? That could be, depending on the resolution, number of, let's say, seconds since midnight, and that's a single counter. And then, you can do some math on it to get hours, minutes, seconds for a particular moment. But really, it's a single quantity, and we can do that with time. We can't do that with a 2D point. Like, it has to have two components. STEPHANIE: So, do you have a recommendation for what unit of time time would best be stored? I'm just thinking of all the times that I've had to do that millisecond, you know, that conversion of, you know, however many thousands of milliseconds in my head into something that actually means [laughs] something to me as a human being who measures time in hours and minutes. JOËL: My recommendation is absolutely go for a single number that you store in your, let's say, time of day object. It makes the math so much easier. You don't have to worry about, like, overflowing from one number into another when you're doing math or anything like that. And then the number that you count should be at the whatever the smallest resolution you care at. So, is there ever any time where you want to distinguish between two different milliseconds in time? Or maybe you're like, you know what? These are, like, we're tracking time of day for appointments. We don't care about the difference between two milliseconds. We don't need to track them independently. We don't even care about seconds. The most granular we ever care about things is by the minute. And so, maybe then your internal number that you track is a counter of minutes since midnight. But if you need more precision, you can go down to seconds or milliseconds or nanoseconds. But yeah, find what is the sort of the least resolution you want to get away with and then make that the unit of measure for a single counter in your object. And then encapsulate that so that nobody else needs to care that, internally, your time of day object is doing milliseconds because nobody wants to do that math. Just give me a nice, like, hours and minutes method on your object, and I will use that. I don't need to know internally what it's using. Please don't just pass around integers; wrap it in an object, especially because integers, there's enough times where you're doing seconds versus milliseconds. And when I just have an integer, I never know if the person storing this integer means seconds or milliseconds. So, I'm just like, oh, I'm going to pass to this, like, user object, a, like, time integer. And unless there's a comment or a constant, you know, that's named something duration in milliseconds or something like that, you know, or sometimes even, like, one year in milliseconds, or there's no way of knowing. STEPHANIE: Yeah. That makes a lot of sense. When you kind of choose a standard of a standard unit, it's, like, possible to make it easier [laughs]. JOËL: So, circling back to sort of the initial thing that sparked this conversation, the previous episode about T-shirt inventories, there we were dealing with what started off as, like, a hash of different T-shirt sizes and quantities of T-shirts that we had in that size, so small (five), medium (three), large (four). And then, we eventually turned that into a value object that represented...I think we called it a tally, but maybe we called it inventory. And this may be wrong, so tell me if I'm wrong here, I think we can kind of treat that as a number, as, like, one of these compound numbers. It's a sort of multidimensional number where you say, well, we have sort of three dimensions where we can have numbers that sort of increase and decrease independently. We can do math on these because we can take inventories or tallies and add and subtract them. And that's what we ended up having to do. We created a value object. We implemented plus and minus on it. There are rules for how the math works. I think this is a multidimensional number with the definition we're working on this show. Am I wrong here? STEPHANIE: I wouldn't say that you're wrong. I think I would have to think a little [laughs] more to say definitively that you're right. But I know that this example came from, you know, an application I was actually working on. And one of the main things that we had to do with these representations [laughs], I'm hesitant to call them a number, especially, but we had to compare these representations frequently because an inventory, for example, in a warehouse, wanting to make sure that it is equal to or there's enough of the inventory if someone was placing an order, which would also contain, like, a representation of T-shirt size inventory. And that was kind of where some of that math happened because, you know, maybe we don't want to let someone place an order if the inventory at the warehouse is smaller than their order, right? So, there is something really compelling about the comparison operations that we were doing that kind of is leaning me in the direction of, like, yeah, like, it makes sense to me to use this in a way that I would compare, like, quantities or numbers of something. JOËL: I think one thing that was really compelling to me, and that kind of blew my mind, was that we were trying to, like, figure out some things like, oh, we've got so many people with these size preferences, and we've got so many T-shirts across different warehouses. And we're summing them up and we're trying to say like, "How many do we need to purchase if there is a deficit?" And we can come up with effectively a formula for this. We're like, sum these numbers, when we're talking about just before we introduce sizes when it's just like, oh, people have T-shirts. They all get the count of people and a count of T-shirts in our warehouse, and we find, you know, the difference between that. And there's a few extra math operations we do. Then you introduce size, and you break it down by, oh, we've got so many of each. And now the whole thing gets really kind of messy and complicated. And you're doing these reduces and everything. When we start treating the tally of T-shirts as an object, and now it's a number that responds to plus and minus, all of a sudden, you can just plug those back into the original formula, and it all just works. The original formula doesn't care whether the numbers you're doing this formula on are simple integers or these sort of multidimensional numbers. And that blew my mind, and it was so cool. STEPHANIE: Yeah, that is really neat. And you get a lot of added benefits, too. I think the other important piece in the T-shirt size example was kind of tracking the state change, and that's so much easier when you have an object. There's just a lot more you can do with it. And even if, you know, you're not persisting every single version of the representation, you know, because sometimes you don't want to, sometimes you're really just kind of only holding it in memory to figure out if you need to, you know, do something else. But other times, you do want to persist it. And it just plugs in really well with, like, the rest of object-oriented programming [laughs] in terms of interacting with the rest of your business needs, I think, in your app. JOËL: Yeah, turns out objects, they're kind of nice. And you can do math with them. Who knew? Math is not just about integers. STEPHANIE: And on that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Joël shares a unique, time-specific bug he encountered, which causes a page to crash only in January. This bug has been fixed in previous years, only to reemerge due to subsequent changes. Stephanie talks about her efforts to bring more structure to her work-from-home environment. She describes how setting up a bird feeder near her desk and keeping chocolates at her desk serve as incentives to work more from her desk. Together, Stephanie and Joël take a deep dive into the challenges of breaking down software development tasks into smaller, more manageable chunks. They explore the concept of 'vertical slice' development, where features are implemented in thin, fully functional segments, contrasting it with the more traditional 'horizontal slice' approach. This discussion leads to insights on collaborative work, the importance of iterative development, and strategies for efficient and effective software engineering. thoughtbot Live Streams (https://www.youtube.com/@thoughtbot/streams?themeRefresh=1) Stephanie's Live Stream (https://www.youtube.com/watch?v=jWmCOMbOxTs) Joël's Talk on Time (https://www.youtube.com/watch?v=54Hs2E7zsQg) Finish the Owl Meme (https://knowyourmeme.com/photos/572078-how-to-draw-an-owl) Full Stack Slices (https://thoughtbot.com/blog/break-apart-your-features-into-full-stack-slices) Elephant Carpaccio (https://blog.crisp.se/2013/07/25/henrikkniberg/elephant-carpaccio-facilitation-guide) Outside-in Feature Development (https://thoughtbot.com/blog/testing-from-the-outsidein) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) 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 in the year 2024? JOËL: Yeah, it's 2024. New year, new me. Or, in this case, maybe new year, new bugs? I'm working on a project where I ran into a really interesting time-specific bug. This particular page on the site only crashes in the month of January. There's some date logic that has a weird boundary condition there, and if you load that page during the month of January, it will crash, but during the entire rest of the year, it's fine. STEPHANIE: That's a fun New Year's tradition for this project [laughs], fixing this bug [laughs] every year. JOËL: It's been interesting because I looked a little bit at the git history of this bug, and it looks like it's been fixed in past Januarys, but then the fix changes the behavior slightly, so people bring the behavior back correct during the rest of the year that also happens to reintroduce the bug in January, and now I'm back to fixing it in January. So, it is a little bit of a tradition. STEPHANIE: Yeah, that is really funny. I was also recently debugging something, and we were having some flakiness with a test that we wrote. And we were trying to figure out because we had some date/time logic as well. And we were like, is there anything strange about this current time period that we are in that would potentially, you know, lead to a flaky test? And we were looking at the clock and we're like, "I don't think it's like, you know, midnight UTC or anything [laughs] like that." But, I mean, I don't know. It's like, how could you possibly think of, like, all of the various weird edge cases, you know, related to that kind of thing? I don't think I would ever be like, huh, it's January, so, surely, that must [laughs] mean that that's this particular edge case I'm seeing. JOËL: It's interesting because I feel like there's a couple of types of time-specific bugs that we see pretty frequently. If you're near the daylight savings boundary, let's say a week before sometimes, or whatever you're...if you're doing, like, a week from now logic or something like that, typically, I'll see failures in the test suite or maybe actual crashes in the code a week before springing forward and a week before falling back. And then, like you said, sometimes you see failures at the end of the day, Eastern time for me, when you approach that midnight UTC time boundary. I think this is the first time I've seen a failure in January due to the month being, like, a month boundary...or it's a year boundary really is what's happening. STEPHANIE: Yeah. That just sounds like another [laughs] thing you have to look out for. I'm curious: are you going to fix this bug for real or leave it for [laughs] 2025? JOËL: I've got a fix that I think is for real and that, like, not only fixes the break in January but also during the rest of the year gives the desired behavior. I think part of what's really interesting about this bug is that there are some subtle behavioral changes between a few different use cases where this code is called, part of which depend on when in the year you're calling it and whether you want to see it for today's date versus you can also specify a date that you want to see this report. And so, it turns out that there are a lot more edge cases than might be initially obvious. So, this turned into effectively a product discussion, and realizing, wait a minute, the code isn't telling the full story. There's more at a product level we need to discuss. And actually, I think I learned a lot about the product there. So, while it was maybe a surprising and kind of humorous bug to come across, I think it was actually a really good experience. STEPHANIE: Nice. That's awesome. That's a pretty good way to start the year, I would say. JOËL: I'd say so. How about you? What's new in your world? STEPHANIE: So, I don't know, I think towards the end of the year, last year, I was in a bit of a slump where I was in that work-from-couch phase of [laughs] the year, you know, like, things are slowing down and I, you know, winter was starting here. I wanted to be cozy, so I'd, you know, set up on the couch with a blanket. And I realized that I really wasn't sitting at my desk at all, and I kind of wanted to bring a little bit of that structure back into my workday, so I [chuckles] added some incentives for me to sit at my desk, which include I recently got a bird feeder that attaches to the window in my office. So, when I sit at my desk, I can hopefully see some birds hanging out. They are very flighty, so I've only seen birds when I'm, like, in the other room. And I'm like, oh, like, there's a bird at the bird feeder. Like, let me get up close to, like, get to admire them. And then as soon as I, like [laughs], get up close to the window, they fly away. So, I'm hoping that if I sit at my desk more, I'll spontaneously see more birds, and maybe they'll get used to, like, a presence closer to the window. And then my second incentive is I now have little chocolates at my desk [laughs]. JOËL: Nice. STEPHANIE: I've just been enjoying, like, a little treat and trying to keep them as a...okay, I've worked at my desk for an hour, and now I get a little reward for that [laughs]. JOËL: I like that. Do you know what kind of species of birds have been coming to your feeder? STEPHANIE: Ooh, yes. So, we got this birdseed mix called Cardinal and Friends [laughs]. JOËL: I love that. STEPHANIE: So, I have seen, like, a really beautiful red male cardinal come by. We get some robins and some chickadees, I think. Part of what I'm excited for this winter is to learn more how to identify more bird species. And I usually like to be out in nature and stuff, and winter is a hard time to do that. So, this is kind of my way of [chuckles] bringing that more into my life during the season. So, this is our first episode after a little bit of a break for the holidays. There actually has been some content of ours that has been published out in the world on the internet [laughs] during this time. And just wanted to point out in the few weeks that there weren't any Bike Shed episodes, I ended up doing a thoughtbot Rails development livestream with thoughtbot CEO Chad Pytel, and that was my first-time live streaming code [laughs]. And it was a really cool experience. I'm glad I had this podcast experience. So, I'm like, okay, well I have, you know, that, like, ability to do stuff kind of off script and present in the moment. But yeah, that was a really cool thing that I got to do, and I feel a little bit more confident about doing those kinds in the future. JOËL: And for those who are not aware, Chad does–I think it's a weekly live stream on Fridays where he's doing various types of code. So, he's done some work on some internal projects. He did a series where he upgraded, I think, a Rails 2 app all the way to Rails 7, typically with a guest who's another teammate from thoughtbot working on a thing. So, for those of our listeners that might find interesting, we'll put a link in the show notes where you can go see that. I think it's on YouTube and on Twitch. STEPHANIE: Yes. JOËL: What did you pair on? What kind of project were you doing for the livestream? STEPHANIE: So, we were working on thoughtbot's internal application called Hub, which is where we have, like, our internal messaging features. It's where we do a lot of our business operations-y things [laughs]. So, all of the, like, agency work that we do, we use our in-house software for that, and so Chad and I were working on a feature to introduce something that would help out with how we staff team members on projects. In other content news [laughs], Joël, I think you have something to share as well. JOËL: Yeah. So, we've mentioned on past episodes that I gave a talk at RubyConf this past November all about what the concept of time actually means within a program and the different ways of representing it, and the fact that time isn't really a single thing but actually kind of multiple related quantities. And over the holiday break, the talks from that conference got published. I'm pretty excited that that is now out there. We'd mentioned that as a highlight in the previous episode, highlighting accomplishments for the year, but it just wasn't quite out yet. We couldn't link it there. So, I'll leave a link in the show notes for this episode for anyone who's interested in seeing that. STEPHANIE: Sounds like that talk is also timely for a debug you -- JOËL: Ha ha ha! STEPHANIE: Were also mentioning earlier in the episode. So, a few episodes ago, I believe we mentioned that we had recently had, like, our company internal hackathon type thing where we have two days to get together and work with team members who we might not normally work with and get some cool projects started or do some team bonding, that kind of thing. And since I'm still, you know, unbooked on client work, I've been doing a lot of internal thoughtbot stuff, like continuing to work on the Hub app I mentioned just a bit ago. And from the hackathon, there was some work that was unfinished by, like, a project team that I decided to pick up this week as part of my internal work. And as I was kind of trying to gauge how much progress was made and, like, what was left to accomplish to get it over the finish line so it could be shipped, I noticed that because there were a couple of different people working on it, they had broken up this feature which was basically introducing, like, a new report for one of our teams to get some data on how certain projects are going. And there was, like, a UI portion and then some back-end portion, and then part of the back-end portion also involved a bit of a complex query that was pulled out as a separate ticket on its own. And so, all of those things were slightly, you know, were mostly done but just needed those, like, finishing touches, and then it also needed to come together. And I ended up pairing on this with another thoughtboter, and we spent the same amount of time that the hackathon was, so two days. We spent those two days on that, like, aspect of putting it all together. And I think I was a bit surprised by how much work that was, you know, we had kind of assumed that like, oh, like, all these pieces are mostly finished, but then the bulk of what we spended our time doing was integrating the components together. JOËL: Does this feel like a bit of a finish the rest of the OWL meme? STEPHANIE: What is that meme? I'm not familiar with it, but now I really want to know [laughs]. JOËL: It's a meme kind of making fun of some of these drawing tutorials where they're like, oh; first you draw, like, three circles. STEPHANIE: [laughs] JOËL: And then just finish the rest of the owl. STEPHANIE: [laughs] JOËL: And I was thinking of this beautifully drawn picture. STEPHANIE: Oh, that's so funny. Okay, yeah, I can see it in my head [laughs] now. It's like how to go from three circles, you know, to a recognizable [laughs] owl animal. JOËL: So, especially, they're like, oh, you know, like, we put in all the core classes and everything. It's all just basically there. You just need to connect it all together, and it's basically done [laughs]. And then you spend a lot of time actually getting that what feels like maybe the last 20 or 10% but takes maybe 80% of the time. STEPHANIE: Yeah, that sounds about right. So, you know, kind of working on that got me thinking about the alternative, which is honestly something that I'm still working on getting better at doing in my day-to-day. But there is this idea of a vertical slice or a full-stack slice, and that, basically, involves splitting a large feature into those full-stack slices. So, you have, like, a fully implemented piece rather than breaking them apart by layers of the stack. So, you know, I just see pretty frequently that, like, maybe you'll have a back-end ticket to do the database migration, to create your models, just whatever, maybe your controllers, or maybe that is even, like, another piece and then, like, the UI component. And those are worked on separately, maybe even by different people. But this vertical slice theory talks about how what you really want is to have a very thin piece of the feature that still delivers value but fully works. JOËL: As opposed to what you might call a horizontal slice, which would be something like, oh, I've built three Rails models. They're there. They're in the code. They talk to tables in the database, but there's nothing else happening with them. So, you've done work, but it's also more or less dead code. STEPHANIE: Yeah, that's a good point. I have definitely seen a lot of unused code paths [laughs] when you kind of go about it that way and maybe, like, that UI ticket never gets completed. JOËL: What are some tips for trying to do some of these narrower slices? Like, I have a ticket, and I have some work I need to do. And I want to break it down because I know it's going to be too big, and maybe the, like, intuitive way to do it is to split it by layers of your stack where I might do all the models, commit, ship that, deploy, then do some controllers, then do some view, or something like that, and you're suggesting instead going full stack. How do you break down the ticket more when all the pieces are interrelated? STEPHANIE: Yeah, that's a great point. One easy way to visualize it, especially if you have designs or something for this feature, right? Oftentimes, you can start to parse out sections or components of the user interface to be shipped separately. Like, yes, you would want all of it to have that rich feature, but if it's a view of some cards or something, and then, yeah, there's, like, the you can filter by them. You can search by them. All of those bits can be broken up to be like, well, like, the very basic thing that a customer would want to see is just that list of cards, and you can start there. JOËL: So, aggressively breaking down the card at, like, almost a product level. Instead of breaking it down by technical pieces, say, like, can we get even smaller amounts of behavior while still delivering value? STEPHANIE: Yeah, yeah, exactly. I like that you said product level because I think another axis of that could also be complexity. So, oftentimes, you know, I'll get a feature, and we're like, oh, we want to support these X number of things that we've identified [laughs]. You know, if it's like an e-com app you're building, you know, you're like, "Do we have all these products that we want to make sure to support?" And, you know, one way to break that down into that vertical slice is to ask, like, what if we started with just supporting one before we add variants or something like that? Teasing out, like, what would end up being the added complexity as you're developing, once you have to start considering multiple parameters, I think that is a good way to be able to start working more iteratively. And so, you don't have to hold all of that complexity in your head. JOËL: It's almost a bit of like a YAGNI principle but applied to features rather than to code. STEPHANIE: Yeah. Yeah. I like that. At first, I hesitated a little bit because I've certainly been in the position where someone has said like, "Well, we do really need this [laughs]." JOËL: Uh-huh. And, sometimes, the answer is, yes, we do need that, but what if I gave you a smaller version of that today, and we can do the other thing tomorrow? STEPHANIE: Right. Yeah, it's not like you're rejecting the idea that it's necessary but the way that you get about to that end result, right? JOËL: So, you keep using the term vertical slice or full-stack slice. I think when I hear that term, I think of specifically an article written by former thoughtboter, German Velasco, on our blog. But I don't know if that's maybe a term that has broader use in the industry. Is that a term that you've heard elsewhere? STEPHANIE: That's a good question. I think I mostly hear, you know, some form of like, "Can we break this ticket down further?" and not necessarily, like, if you think about how, right? I'm, like, kind of doing a motion with my hand [chuckles] of, like, slicing from top to bottom as opposed to, you know, horizontal. Yeah, I think that it may not be as common as I wish it were. Even if there's still some amount of adapting or, like, persuading your team members to get on board with this idea, like, I would be interested in, like, introducing that concept or that vocabulary to get teams talking about, like, how do they break down tickets? You know, like, what are they considering? Like, what alternatives are there? Like, are horizontal slices working for them or not? JOËL: A term that I've heard floating around and I haven't really pinned down is Elephant Carpaccio. Have you heard that before? STEPHANIE: I have, only because I, like, discovered a, like, workshop facilitation guide to run an exercise that is basically, like, helping people learn how to identify, like, smaller and smaller full-stack slices. But with the Elephant Carpaccio analogy, it's kind of like you're imagining a feature as big as an elephant. And you can create, like, a really thin slice out of them, and you can have infinite number of slices, but they still end up creating this elephant. And I guess you still get the value of [chuckles] a little carpaccio, a delicious [laughs] appetizer of thinly sliced meat. JOËL: I love a colorful metaphor. So, I'm curious: in your own practice, do you have any sort of guidelines or even heuristics that you like to use to help work in a more, I guess, iterative fashion by working with these smaller slices? STEPHANIE: Yeah, one thought that I had about it is that it plays really well with Outside-In Test Driven Development. JOËL: Hmmm. STEPHANIE: Yeah. So, if, you know, you are starting with a feature test, you have to start somewhere and, you know, maybe starting with, like, the most valuable piece of the feature, right? And you are starting at that level of user interaction if you're using Capybara, for example. And then it kind of forces you to drop down deeper into those layers. But once you go through that whole process of outside-in and then you arrive back to the top, you've created your full-stack feature [laughs], and that is shippable or, like, committable and, you know, potentially even shippable in and of itself. And you already have full test coverage with it. And that was a cool way that I saw some of those two concepts work well together. JOËL: Yeah, there is something really fun about the sort of Red-Green-Refactor cycle that TDD forces on you and that you're typically writing the minimum code required to pass a test. And it really forces you out of that developer brain where you're just like, oh, I've got to cover my edge cases. I've got to engineer for some things. And then maybe you realize you've written code that wasn't necessary. And so, I've found that often when I do, like, actually TDD a feature, I end up with code that's a lot leaner than I would otherwise. STEPHANIE: Yes, lean like a thin slice of Elephant Carpaccio. [laughter] JOËL: One thing you did mention that I wanted to highlight was the fact that when you do this outside-in approach for your tiny slice, at the end, it is shippable. And I think that is a core sort of tenet of this idea is that even though you're breaking things down into smaller and smaller slices, every slice is shippable to production. Like, it doesn't break the build. It doesn't break the website. And it provides some kind of value to the user. STEPHANIE: Yeah, absolutely. I think one thing that I still kind of get hung up on sometimes, and I'm trying to, you know, revisit this assumption is that idea of, like, is this too small? Like, is this valuable enough? When I mentioned earlier that I was working on a report, I think there was a part of me that's like, could I just ship a report with two columns [laughs]? And the answer is yes, right? Like, I thought about it, and I was like, well, if that data is, like, not available anywhere else, then, yeah, like, that would be valuable to just get out there. But I think the idea that, like, you know, originally, the hope was to have all of these things, these pieces of information, you know, available through this report, I think that, like, held me back a little bit from wanting to break it down. And I held it a little bit too closely and to be like, well, I really want to, like, you know, deliver something impressive. When you click on it, it's like, wow, like, look at all this data [laughs]. So, I'm trying to push back a little bit on my own preconceived notions that, like, there is such a thing as, like, a too small of a demo. JOËL: I've often worked with this at a commit level, trying to see, like, how small can I get a commit, and what is too small? And now you get into sort of the fraught question of what is a, you know, atomic commit? And I think, for me, where I've sort of come down is that a commit must pass CI. Like, I don't want a commit that's going to go into the main branch. I'm totally pro-work-in-progress commits on a branch; that's fine. But if it's going to get shipped into the main branch, it needs to be green. And it also cannot introduce dead code. STEPHANIE: Ooh. JOËL: So, if you're getting to the point where you're breaking either of those, you've got some sort of, like, partial commit that's maybe too small that needs more to be functional. Or you maybe need to restructure to say, look, instead of adding just ten models, can I add one model but also a little bit of a controller and a view? And now I've got a vertical slice. STEPHANIE: Yeah, which might even be less code [laughs] in the end. JOËL: Yes, it might be less code. STEPHANIE: I really like that heuristic of not introducing dead code, that being a goal. I'm going to think about that a lot [laughs] and try to start introducing that into when I think something is ready. JOËL: Another thing that I'll often do, I guess, that's almost like it doesn't quite fit in the slice metaphor, but it's trying to separate out any kind of refactor work into its own commit that is, you know, still follows those rules: it does not introduce dead code; it does not break the build; it's independently shippable. But that might be something that I do that sets me up for success when I want to do that next slice. So, maybe I'm trying to add a new feature, but just the way we built some of the internal models, they don't have the interface that I need right now, and that's fine because I don't want to build these models in anticipation of the future. I can change them in the future if I need. But now the future has come, and I need a slightly different shape. So, I start by refactoring, commit, maybe even ship that deploy. Maybe I then do my small feature afterwards. Maybe I come back next week and do the small feature, but there are two independent things, two different commits, maybe two different deploys. I don't know that I would call that refactor a slice and that it maybe goes across the full stack; maybe it doesn't. It doesn't show to the user because a refactor, by definition, is just changing the implementation without changing behavior. But I do like to break that out and keep it separate. And I guess it helps keep my slices lean, but I'm not quite sure where refactors fit into this metaphor. STEPHANIE: Yeah, that's interesting because, in my head, as I was listening to you talk about that, I was visualizing the owl again, the [laughs] owl meme. And I'm imagining, like, the refactoring making the slice richer, right? It's like you're adding details, and you're...it's like when you end up with the full animal, or the owl, the elephant, whatever, it's not just, like, a shoddy-looking drawing [laughs]. Like, ideally, you know, it has those details. Maybe it has some feathers. It's shaded in, and it is very fleshed out. That's just my weird, little brain trying [laughs] to stretch this metaphor to make it work. Another thing that I want to kind of touch a little bit more about when we're talking about how a lot of the work I was spending recently was that glue work, you know, the putting the pieces together, I think there was some aspect of discovery involved that was missed the first time around when these tickets were broken up more horizontally. I think that one really important piece that I was doing was trying to reconcile the different mental models that each person had when they were working on their separate piece. And so, maybe there's, like, an API, and then the frontend is expecting some sort of data, and, you know, you communicate it in a way that's, like, kind of hand-off-esque. And then when you put it together, it turns out that, oh, the pieces don't quite fit together, and how do you actually decide, like, what that mental model should be? Naming, especially, too, I've, you know, seen so many times when the name...like, an attribute on the frontend is named a little bit different than whatever is on the backend, and it takes a lot of work to unify that, like, to make that decision about, should they be the same? Should they be different? A lot of thought goes into putting those pieces together. And I think the benefit of a full-stack slice is that that work doesn't get lost. Especially if you are doing stuff like estimating, you're kind of discovering that earlier on. And I think what I just talked about, honestly, is what prevents those features from getting shipped in the end if you were working in a more horizontal way. JOËL: Yeah. It's so easy to have, like, big chunks of work in progress forever and never actually shipping. And one of the benefits of these narrower slices is that you're shipping more frequently. And that's, you know, interesting from a coding perspective, but it's kind of an agile methodology thing as well, the, like, ship smaller chunks more frequently. Even though you're maybe taking a little bit more overhead because you're having to, like, take the time to break down tasks, it will make your project move faster as a whole. An aspect that's really interesting to me, though, is what you highlighted about collaboration and the fact that every teammate has a slightly different mental model. And I think if you take the full-stack slice and every member is able to use their mental model, and then close the loop and actually, like, do a complete thing and ship it, I think it allows every other member who's going to have a slightly different mental model of the problem to kind of, yes, and... the other person rather than all sort of independently doing their things and having to reconcile them at the end. STEPHANIE: Yeah, I agree. I think I find, you know, a lot of work broken out into backend and frontend frequently because team members might have different specialties or different preferences about where they would like to be working. But that could also be, like, a really awesome opportunity for pairing [laughs]. Like, if you have someone who's more comfortable in the backend or someone more comfortable in the frontend to work on that full-stack piece together, like, even outside of the in-the-weeds coding aspects of it, it's like you're, at the very least, making sure that those two folks have that same mental model. Or I like what you said about yes, and... because it gets further refined when you have people who are maybe more familiar with, like, something about the app, and they're like, "Oh, like, don't forget about we should consider this." I think that, like, diversity of experience, too, ends up being really valuable in getting that abstraction to be more accurate so that it best represents what you're trying to build. JOËL: Early on, when I was pretty new working at thoughtbot, somebody else at the company had given me the advice that if I wanted to be more effective and work faster on projects, I needed to start breaking my work down into smaller chunks, and this is, you know, fairly junior developer at the time. The advice sounds solid, and everything we've talked about today sounds really solid. Doing it in practice is hard, and it's taken me, you know, a decade, and I'm still working on getting better at it. And I wrote an article about working iteratively that covers a lot of different elements where I've kind of pulled on threads and found out ways where you can get better at this. But I do want to acknowledge that this is not something that's easy and that just like the code that we're working on iteratively, our technique for breaking things down is something that we improve on iteratively. And it's a journey we're all on together. STEPHANIE: I'm really glad that you brought up how hard it is because as I was thinking about this topic, I was considering barriers into working in that vertical slice way, and barriers that I personally experience, as well as just I have seen on other teams. I had alluded to some earlier about, like, the perception of if I ship this small thing, is it impressive enough, or is it valuable enough? And I think I realized that, like, I was getting caught up in, like, the perception part, right? And maybe it doesn't matter [chuckles], and I just need to kind of shift the way I'm thinking about it. And then, there are more real barriers or, like, concrete barriers that are tough. Long feedback loops is one that I've encountered on a team where it's just really hard to ship frequently because PR reviews aren't happening fast enough or your CI or deployment process is just so long that you're like, I want to stuff everything into [chuckles] this one PR so that at least I won't have to sit and wait [laughs]. And that can be really hard to work against, but it could also be a really interesting signal about whether your processes are working for you. It could be an opportunity to be like, "I would like to work this way, but here are the things that are preventing me from really embracing it. And is there any improvement I can make in those areas?" JOËL: Yeah. There's a bit of a, like, vicious cycle that happens there sometimes, especially around PR review, where when it takes a long time to get reviews, you tend to decide, well, I'm going to not make a bunch of PRs; I'm going to make one big one. But then big PRs are very, like, time intensive and require you to commit a lot of, like, focus and energy to them, which means that when you ask me for a review, I'm going to wait longer before I review it, which is going to incentivize you to build bigger PRs, which is going to incentivize me to wait longer, and now we just...it's a vicious cycle. So, I know I've definitely been on projects where a question the team has had is, "How can we improve our process? We want faster code review." And there's some aspect of that that's like, look, everybody just needs to be more disciplined or more alert and try to review things more frequently. But there's also an element of if you do make things smaller, you make it much easier for people to review your code in between other things. STEPHANIE: Yeah, I really liked you mentioning incentives because I think that could be a really good place to start if you or your team are interested in making a change like this, you know, making an effort to look at your team processes and being like, what is incentivized here, and what does our system encourage or discourage? And if you want to be making that shift, like, that could be a good place to start in identifying places for improvement. JOËL: And that happens on a broader system level as well. If you look at what does it take to go from a problem that is going to turn into a ticket to in-production in front of a client, how long is that loop? How complex are the steps to get there? The longer that loop is, the slower you're iterating. And the easier it is for things to just get hung up or for you to waste time, the harder it is for you to change course. And so, oftentimes, I've come on to projects with clients and sort of seen something like that, and sort of seen other pain points that the team has and sort of found that one of the root causes is saying, "Look, we need to tighten that feedback loop, and that's going to improve all these other things that are kind of constellation around it." STEPHANIE: Agreed. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Joël shares his experiences with handling JSON in a Postgres database. He talks about his challenges with ActiveRecord and JSONB columns, particularly the unexpected behavior of storing and retrieving JSON data. Stephanie shares her recent discovery of bookmarklets and highlights a bookmarklet named "Check This Out," which streamlines searching for books on Libby, an ebook and audiobook lending app. The conversation shifts to using constants in code as a form of documentation. Stephanie and Joël discuss how constants might not always accurately reflect current system behavior or logic, leading to potential misunderstandings and the importance of maintaining accurate documentation. Bookmarklets (https://www.freecodecamp.org/news/what-are-bookmarklets/) "Check This Out" Bookmarklet (https://checkthisout.today/) Libby (https://libbyapp.com/interview/welcome#doYouHaveACard) Productivity Tricks (https://www.bikeshed.fm/403) 12 Factor App Config (https://12factor.net/config) A Hierarchy of Documentation (https://challahscript.com/hiearchy_of_documentation) Sustainable Rails (https://sustainable-rails.com/) rails-erd gem (https://github.com/voormedia/rails-erd) 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: What's new in my world is JSON and how to deal with it in a Postgres database. So, I'm dealing with a situation where I have an ActiveRecord model, and one of the columns is a JSONB column. And, you know, ActiveRecord is really nice. You can just throw a bunch of different data at it, and it knows the column type, and it will do some conversions for you automatically. So, if I'm submitting a form and, you know, form values might come in as strings because, you know, I typed in a number in a text field, but ActiveRecord will automatically parse that into an integer because it knows we're saving that to an integer column. So, I don't need to do all these, like, manual conversions. Well, I have a form that has a string of JSON in it that I'm trying to save in a JSONB column. And I expected ActiveRecord to just parse that into a hash and store it in Postgres. That is not what happens. It just stores a raw string, so when I pull it out again, I don't have a hash. I have a raw string that I need to deal with. And I can't query it because, again, it is a raw string. So, that was a bit of an unexpected behavior that I saw there. STEPHANIE: Yeah, that is unexpected. So, is this a field that has been used for a while now? I'm kind of surprised that there hasn't been already some implementations for, like, deserializing it. JOËL: So, here's the thing: I don't think you can have an automatic deserialization there because there's no way of knowing whether or not you should be deserializing. The reason is that JSON is not just objects or, in Ruby parlance, hashes. You can also have arrays. But just raw numbers not wrapped in hashes are also valid JSON as are raw strings. And if I just give you a string and say, put this in a JSON field, you have no way of knowing, is this some serialized JSON that you need to deserialize and then save? Or is it just a string that you should save because strings are already JSON? So, that's kind of on you as the programmer to make that distinction because you can't tell at runtime which one of these it is. STEPHANIE: Yeah, you're right. I just realized it's [laughs] kind of, like, an anything goes [laughs] situation, not anything but strings are JSON, are valid JSON, yep [laughs]. That sounds like one of those things that's, like, not what you think about immediately when dealing with that kind of data structure, but... JOËL: Right. So, the idea that strings are valid JSON values, but also all JSON values can get serialized as strings. And so, you never know: are you dealing with an unserialized string that's just a JSON value, or are you dealing with some JSON blob that got serialized into a string? And only in one of those do you want to then serialize before writing into the database. STEPHANIE: So, have you come to a solution or a way to make your problem work? JOËL: So, the solution that I did is just calling a JSON parse before setting that attribute on my model because this value is coming in from a form. I believe I'm doing this when I'm defining the strong parameters for that particular form. I'm also transforming that string by parsing it into a hash with the JSON dot parse, which then gets passed to the model. And then I'm not sure what JSONB serializes as under the hood. When you give it a hash, it might store it as a string, but it might also have some kind of binary format or some internal AST that it uses for storage. I'm not sure what the implementation is. STEPHANIE: Are the values in the JSONB something that can be variable or dynamic? I've seen some people, you know, put that in getter so that it's just kind of done for you for anyone who needs to access that field. JOËL: Right now, there is a sort of semi-consistent schema to that. I think it will probably evolve to where I'll pull some of these out to be columns on the table. But it is right now kind of an everything else sort of dumping ground from an API. STEPHANIE: Yeah, that's okay, too, sometimes [laughs]. JOËL: Yeah. So, interesting journey into some of the fun edge cases of dealing with a format whose serialized form is also a valid instance of that format. What's been new in your world? STEPHANIE: So, I discovered something new that has been around on the internet for a while, but I just haven't been aware of it. Do you know what a bookmarklet is? JOËL: Oh, like a JavaScript code that runs in a bookmark? STEPHANIE: Yeah, exactly. So, you know, in your little browser bookmark where you might normally put a URL, you can actually stick some JavaScript in there. And it will run whenever you click your bookmark in your browser [chuckles]. So, that was a fun little internet tidbit that I just found out about. And the reason is because I stumbled upon a bookmarklet made by someone. It's called Check This Out. And what it does is there's another app/website called Libby that is used to check out ebooks and audiobooks for free from your local public library. And what this Check This Out bookmarklet does is you can kind of select any just, like, text on a web page, and then when you click the bookmarklet, it then just kind of sticks it into the query params for Libby's search engine. And it takes you straight to the results for that book or that author, and it saves you a few extra manual steps to go from finding out about a book to checking it out. So, that was really neat and cute. And I was really surprised that you could do that. I was like, whoa [laughs]. At first, I was like, is this okay? [laughs] If you, like, you can't read, you know, you don't know what the JavaScript is doing, I can see it being a little sketchy. But –- JOËL: Be careful of executing arbitrary JavaScript. STEPHANIE: Yeah, yeah. When I did look up bookmarklets, though, I kind of saw that it was, you know, just kind of a fun thing for people who might be learning to code for the first time to play around with. And some fun ideas they had for what you could do with it was turning all the font on a web page to Comic Sans [laughs]. So yeah, I thought that was really cute. JOËL: Has that inspired you to write your own? STEPHANIE: Well, we did an episode a while ago on productivity tricks. And I was thinking like, oh yeah, there's definitely some things that I could do to, you know, just stick some automated tasks that I have into a bookmarklet. And that could be a really fun kind of, like, old-school way of doing it, as opposed to, you know, coding my little snippets or getting into a new, like, Omnibar app [laughs]. JOËL: So, something that is maybe a little bit less effort than building yourself a browser extension or something like that. STEPHANIE: Yeah, exactly. JOËL: I had a client project once that involved a...I think it was, like, a five-step wizard or something like that. It was really tedious to step through it all to manually test things. And so, I wrote a bookmarklet that would just go through and fill out all the fields and hit submit on, like, five pages worth of these things. And if anything didn't work, it would just pause there, and then you could see it. In some way, it was moving towards the direction of, like, an automated like Capybara style test. But this was something that was helping for manual QA. So, that was a really fun use of a bookmarklet. STEPHANIE: Yeah, I like that. Like, just an in-between thing you could try to speed up that manual testing without getting into, like you said, an automated test framework for your browser. JOËL: The nice thing about that is that this could be used without having to set up pretty much anything, right? You paste a bit of JavaScript into your bookmark bar, and then you just click the button. That's all you need to do. No need to make sure that you've got Ruby installed on your machine or any of these other things that you would need for some kind of testing framework. You don't need Selenium. You don't need ChromeDriver. It just...it works. So, I was working...this was a greenfield startup project. So, I was working with a non-technical founder who didn't have all these things, you know, dev tooling on his machine. So, he wanted to try out things but not spend his days filling out forms. And so, having just a button he could click was a really nice shortcut. STEPHANIE: That's really cool. I like that a lot. I wasn't even thinking about how I might be able to bring that in more into just my daily work, as opposed to just something kind of fun. But that's an awesome idea. And I hope that maybe I'll have a good use for one in the future. JOËL: It feels like the thing that has a lot of potential, and yet I have not since written...I don't think I've written any bookmarklets for myself. It feels like it's the kind of thing where I should be able to do this for all sorts of fun tooling and just automate my life away. Somehow, I haven't done that. STEPHANIE: Bring back the bookmarklet [laughs]. That's what I have to say. JOËL: So, I mentioned earlier that I was working with a JSONB column and storing JSON on an ActiveRecord model. And then I wanted to interact with it, but the problem is that this JSON is somewhat arbitrary, and there are a lot of magic strings in there. All of the key names might change. And I was really concerned that if the schema of that JSON ever changed, if we changed some of the key names or something like that, we might accidentally break code in multiple parts of the app. So, I was very careful while building that model to quarantine any references to any raw strings only within that model, which meant that I leaned really heavily on constants. And, in some way, those constants end up kind of documenting what we think the schema of that JSON should be. And that got me thinking; you were telling me recently about a scenario where some code you were working with relied heavily on constants as a form of documentation, and that documentation kind of lied to you. STEPHANIE: Yeah, it did. And I think you mentioned something that I wanted to point out, which is that the magic strings that you think might change, and you wanted to pull that out into a constant, you know, so at least it's kind of defined in one place. And if it ever does change, you know, you don't have to change it in all of those places. And I do think that, normally, you know, if there's opportunities to extract those magic strings and give a name to them, that is beneficial. But I was gripping a little bit about when constants become, I guess, like, too wieldy, or there's just kind of, like, too much of a dependency on them as the things documenting how the app should work when it's constantly changing. I realized that I just used constant and constantly [laughs]. JOËL: The only constant is that it is not constant. STEPHANIE: Right. And so, the situation that I found myself in—this was on a client project a little bit ago—was that the constants became, like, gatekeepers of that logic where dev had to change it if the app's behavior changed, and maybe we wanted to change the value of it. And also, one thing that I noticed a lot was that we, as developers, were getting questions about, "Hey, like, how does this actually work?" Like, we were using the constants for things like pricing of products, for things like what is a compatible version for this feature. And because that was only documented in the code, other people who didn't have access to it actually were left in the dark. And because those were changing with somewhat frequency, I was just kind of realizing how that was no longer working for us. JOËL: Would you say that some of these values that we stored as constants were almost more like config rather than constants or maybe they're just straight-up application data? I can imagine something like price of an item you probably want that to be a value in the database that can be updated by an admin. And some of these other things maybe are more like config that you change through some kind of environment variable or something like that. STEPHANIE: Yeah, that's a good point. I do think that they evolved to become things that needed to be configured, right? I suppose maybe there wasn't as much information or foresight at the beginning of like, oh, this is something that we expect to change. But, you know, kind of when you're doing that first pass and you're told, like, hey, like, this value should be the price of something, or, like, the duration of something, or whatever that may be. It gets codified [chuckles]. And there is some amount of lift to change it from something that is, at first, just really just documenting what that decision was at the time to something that ends up evolving. JOËL: How would you draw a distinction between something that should be a constant versus something that maybe would be considered config or some other kind of value? Because it's pretty easy, right? As developers, we see magic numbers. We see magic strings. And our first thought is, oh, we've seen this problem before—constant. Do you have maybe a personal heuristic for when to reach for a constant versus when to reach for something else? STEPHANIE: Yeah, that's a good question. I think when I started to see it a lot was especially when the constants were arrays or hashes [laughs]. And I guess that is actually kind of a signal, right? You will likely be adding more stuff [laughs] into that data structure [laughs]. And, again, like, maybe it's okay, like, the first couple of times. But once you're seeing that request happen more frequently, that could be a good way to advocate for storing it in the database or, like, building a lightweight admin kind of thing so that people outside of the dev team can make those configuration changes. I think also just asking, right? Hey, like, how often do we suspect this will change? Or what's on the horizon for the product or the team where we might want to introduce a way to make the implementation a bit more flexible to something that, you know, we think we know now, but we might want to adjust for? JOËL: So, it's really about change and how much we think this might change in the future. STEPHANIE: Speaking of change, this actually kind of gets into the broader topic of documentation and how to document a changing and evolving entity [chuckles], you know, that being, like, the codebase or the way that decisions are made that impact how an application works. And you had shared, in preparation for this topic, an article that I read and enjoyed called Hierarchy of Documentation. And one thing that I liked about it is that it kind of presented all of the places that you could put information from, you know, straight in the code, to in your commit messages, to your issue management system, and to even wikis for your repo or your team. And I think that's actually something that we would want to share with new developers, you know, who might be wondering, like, where do I find or even put information? I really liked how it was kind of, like, laid out and gave, like, different reasons for where you might want to put something or not. JOËL: We think a lot about documentation as code writers. I'm curious what your experience is as a code reader. How do you tend to try to read code and understand documentation about how code works? And, apparently, the answer is, don't read the constants because these constants lie. STEPHANIE: I think you are onto something, though, because I was just thinking about how distrustful I've become of certain types of documentation. Like, when I think of code comments, on one hand, they should be a signal, right? They should kind of draw your attention to something maybe weird or just, like, something to note about the code that it's commenting on, or where it's kind of located in a file. But I sometimes tune them out, I'm not going to lie. When I see a really big block of code [chuckles] comment, I'm like, ugh, like, do I really have to read all of this? I'm also not positive that it's still relevant to the code below it, right? Like, I don't always have git blame, like, visually enabled in my editor. But oftentimes, when I do a little bit of digging, that comment is left over from maybe when that code was initially introduced. But, man, there have been lots of commits [chuckles] in the corresponding, you know, like, function sense, and I'm not really sure how relevant it is anymore. Do you struggle with the signal versus noise issue with code comments? How much do you trust them, and how much do you kind of, like, give credence to them? JOËL: I think I do tend to trust them with maybe some slight skepticism. It really depends on the codebase. Some codebases are really bad sort of comment hygiene and just the types of comments that they put in there, and then others are pretty good at it. The ones that I tend to particularly appreciate are where you have maybe some, like, weird function and you're like, what is going on here? And then you've got a nice, little paragraph up top explaining what's going on there, or maybe an explanation of ways you might be tempted to modify that piece of code and, like, why it is the way it is. So, like, hey, you might be wanting to add an extra branch here to cover this edge case. Don't do that. We tried it, and it causes problems for XY reasons. And sometimes it might be, like, a performance thing where you say, look, the code quality person in you is going to look at this and say, hey, this is hard to read. It would be better if we did this more kind of normalized form. Know that we've particularly written this in a way that's hard to read because it is more performant, and here are the numbers. This is why we want it in this way. Here's a link to maybe the issue, or the commit, or whatever where this happened. And then if you want to start that discussion up again and say, "Hey, do we really need performance here at the cost of readability?", you can start it up again. But at least you're not going to just be like, oh, while I'm here, I'm going to clean up this messy code and accidentally cause a regression. STEPHANIE: Yeah. I like what you said about comment hygiene being definitely just kind of, like, variable depending on the culture and the codebase. JOËL: I feel like, for myself, I used to be pretty far on the spectrum of no comments. If I feel the need to write a comment, that's a smell. I should find other ways to communicate that information. And I think I went pretty far down that extreme, and then I've been slowly kind of coming back. And I've probably kind of passed the center, where now I'm, like, slightly leaning towards comments are actually nice sometimes. And they are now a part of my toolkit. So, we'll see if I keep going there. Maybe I'll hit some point where I realize that I'm putting too much work into comments or comments are not being helpful, and I need to come back towards the center again and focus on other ways of communicating. But right now, I'm in that phase of doing more comments than I used to. How about you? Where do you stand on that sort of spectrum of all information should be communicated in code tokens versus comments? STEPHANIE: Yeah, I think I'm also somewhere in the middle. I think I have developed an intuition of when it feels useful, right? In my gut, I'm like, oh, I'm doing something weird. I wish I didn't have to do this [chuckles]. I think it's another kind of intuition that I have now. I might leave a comment about why, and I think that is more of that signal, right? Though I also recently have been using them more as just, like, personal notes for myself as I'm, you know, in my normal development workflow, and then I will end up cleaning them up later. I was working on a codebase where there was a soft delete functionality. And that was just, like, a concern that was included in some of the models. And I didn't realize that that's what was going on. So, when I, you know, I was calling destroy, I thought it was actually being deleted, and it turns out it wasn't. And so, that was when I left a little comment for myself that was like, "Hey, like, this is soft deleted." And some of those things I do end up leaving if I'm like, yes, other people won't have the same context as me. And then if it's something that, like, well, people who work in this app should know that they have soft delete, so then I'll go ahead and clean that up, even though it had been useful for me at the time. JOËL: Do you capture that information and then put it somewhere else then? Or is it just it was useful for you as a stepping-stone on the journey but then you don't need it at the end and nobody else needs to care about it? STEPHANIE: Oh, you know what? That's actually a really great point. I don't think I had considered saving that information. I had only thought about it as, you know, just stuff for me in this particular moment in time. But that would be really great information to pull out and put somewhere else [chuckles], perhaps in something like a wiki, or like a README, or somewhere that documents things about the system as a whole. Yeah, should we get into how to document kind of, like, bigger-picture stuff? JOËL: How do you feel about wikis? Because I feel like I've got a bit of a love-hate relationship with them. STEPHANIE: I've seen a couple of different flavors of them, right? Sometimes you have your GitHub wiki. Sometimes you have your Confluence ecosystem [laughs]. I have found that they work better if they're smaller [laughs], where you can actually, like, navigate them pretty well, and you have a sense of what is in there, as opposed to it just being this huge knowledge base that ends up actually, I think, working against you a little bit [laughs]. Because so much information gets duplicated if it's hard to find and people start contributing to it maybe without keeping in mind, like, the audience, right? I've seen a lot of people putting in, like, their own personal little scripts [laughs] in a wiki, and it works for them but then doesn't end up working for really anyone else. What's your love-hate relationship to them? JOËL: I think it's similar to what you were saying, a little bit of structure is nice. When they've just become dumping grounds of information that is maybe not up to date because over the course of several years, you end up with a lot of maybe conflicting articles, and you don't know which one is the right thing to do, it becomes hard to find things. So, when it just becomes a dumping ground for random information related to the company or the app, sometimes it becomes really challenging to find the information I need and to find information that's relevant, to the point where oftentimes looking something up in the wiki is my last resort. Like, I'm hoping I will find the answer to my question elsewhere and only fallback to the wiki if I can't. STEPHANIE: Yeah, that's, like, the sign that the wiki is really not trustworthy. And it kind of is diminishing returns from there a bit. I think I fell into this experience on my last project where it was a really, really big wiki for a really big codebase for a lot of developers. And there was kind of a bit of a tragedy of the commons situation, where on one hand, there were some things that were so manual that the steps needed to be very explicitly documented, but then they didn't work a lot of the time [laughs]. But it was hard to tell if they weren't working for you or because it was genuinely something wrong with, like, the way the documentation laid out the steps. And it was kind of like, well, I'm going to fix it for myself, but I don't know how to fix it for everyone else. So, I don't feel confident in updating this information. JOËL: I think that's what's really nice about the article that you mentioned about the hierarchy of documentation. It's that all of these different forms—code, comments, commit messages, pull requests, wikis—they don't have to be mutually exclusive. But sometimes they work sort of in addition to each other sort of each adding more context. But also, sometimes it's you sort of choose the one that's the highest up on that list that makes sense for what you're trying to do, so something like documenting a series of steps to do something maybe a wiki is a good place for that. But maybe it's better to have that be executable. Could that be a script somewhere? And then maybe that can be a thing that is almost, like, living documentation, but also where you don't need to maybe even think about the individual steps anymore because the script is running, you know, 10 different things. And I think that's something that I really appreciated from the book Sustainable Rails is there's a whole section there talking about the value of setup scripts and how people who are getting started on your app don't want to have to care about all the different things to set it up, just run a script. And also, that becomes living documentation for what the app needs, as opposed to maybe having a bulleted list with 10 elements in it in your project README. STEPHANIE: Yeah, absolutely. In the vein of living documentation, I think one thing that wikis can be kind of nice for is for putting visual supplements. So, I've seen them have, like, really great graphs. But at the same time, you could use a gem like Rails-ERD that generates the entity relationship diagram as the schema of your database changes, right? So, it's always up to date. I've seen that work well, too, when you want to have, like I said, those, like, system-level documentation that sometimes they do change frequently and, you know, sometimes they don't. But that's definitely worth keeping in mind when you choose, like, how you want to have that exist as information. JOËL: How do you feel about deleting documentation? Because I feel like we put so much work into writing documentation, kind of like we do when writing tests. It feels like more is always better. Do you ever go back and maybe sort of prune some of your docs, or try to delete some things that you think might no longer be relevant or helpful? STEPHANIE: I was also thinking of tests when you first posed that question. I don't know if I have it in my practice to, like, set aside time and be like, hmm, like, what looks outdated these days? I am starting to feel more confident in deleting things as I come across them if I'm like, I just completely ignored this or, like, this was just straight up wrong [laughs]. You know, that can be scary at first when you aren't sure if you can make that determination. But rather than thrust that, you know, someone else going through that same process of spending time, you know, trying to think about if this information was useful or not, you can just delete it [laughs]. You can just delete tests that have been skipped for months because they don't work. Like, you can delete information that's just no longer relevant and, in some ways, causing you more pain because they are cluttering up your wiki ecosystem so that no one [laughs] feels that any of that information is relevant anymore. JOËL: I'll be honest, I don't think I've ever deleted a wiki article that was out of date or no longer relevant. I think probably the most I've done is go to Slack and complain about how an out-of-date wiki page led me down the wrong path, which is probably not the most productive way to channel those feelings. So, maybe I should have just gone back and deleted the wiki page. STEPHANIE: I do like to give a heads up, I think. It's like, "Hey, I want to delete this thing. Are there any qualms?" And if no one on your team can see a reason to keep it and you feel good about that it's not really, like, serving its purpose, I don't know, maybe consider just doing it. JOËL: To kind of wrap up this topic, I've got a spicy question for you. STEPHANIE: Okay, I'm ready. JOËL: Do you think that AI is going to radically change the way that we interact with documentation? Imagine you have an LLM that you train on maybe not just your code but the Git history. It has all the Git comments and maybe your wiki. And then, you can just ask it, "Why does function foo do this thing?" And it will reference a commit message or find the correct wiki article. Do you think that's the future of understanding codebases? STEPHANIE: I don't know. I'm aware that some people kind of can see that as a use case for LLMs, but I think I'm still a little bit nervous about the not knowing how they got there kind of part of it where, you know, yes, like I am doing this manual labor of trying to sort out, like, is this information good or trustworthy or not? But at least that is something I'm determining for myself. So, that is where my skepticism comes in a little bit. But I also haven't really seen what it can do yet or seen the outcomes of it. So, that's kind of where I'm at right now. JOËL: So, you think, for you, the sort of the journey of trying to find and understand the documentation is a sort of necessary part of building the understanding of what the code is doing. STEPHANIE: I think it can be. Also, I don't know, maybe my life would be better by having all that cut out for me, or I could be burned by it because it turns out that it was bad information [laughs]. So, I can't say for sure. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Joël recaps his time at RubyConf! He shares insights from his talk about different aspects of time in software development, emphasizing the interaction with the audience and the importance of post-talk discussions. Stephanie talks about wrapping up a long-term client project, the benefits of change and variety in consulting, and maintaining a balance between project engagement and avoiding burnout. They also discuss strategies for maintaining work-life balance, such as physical separation and device management, particularly in a remote work environment. Rubyconf (https://rubyconf.org/) Joël's talk slides (https://speakerdeck.com/joelq/which-time-is-it) Flaky test summary slide (https://speakerdeck.com/aridlehoover/the-secret-ingredient-how-to-understand-and-resolve-just-about-any-flaky-test?slide=170) 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: Well, as of this recording, I have just gotten back from spending the week in San Diego for RubyConf. STEPHANIE: Yay, so fun. JOËL: It's always so much fun to connect with the community over there, talk to other people from different companies who work in Ruby, to be inspired by the talks. This year, I was speaking, so I gave a talk on time and how it's not a single thing but multiple different quantities. In particular, I distinguish between a moment in time like a point, a duration and amount of time, and then a time of day, which is time unconnected to a particular day, and how those all connect together in the software that we write. STEPHANIE: Awesome. How did it go? How was it received? JOËL: It was very well received. I got a lot of people come up to me afterwards and make a variety of time puns, which those are so easy to make. I had to hold myself back not to put too many in the talk itself. I think I kept it pretty clean. There were definitely a couple of time puns in the description of the talk, though. STEPHANIE: Yeah, absolutely. You have to keep some in there. But I hear you that you don't want it to become too punny [laughs]. What I really love about conferences, and we've talked a little bit about this before, is the, you know, like, engagement and being able to connect with people. And you give a talk, but then that ends up leading to a lot of, like, discussions about it and related topics afterwards in the hallway or sitting together over a meal. JOËL: I like to, in my talks, give little kind of hooks for people who want to have those conversations in the hallway. You know, sometimes it's intimidating to just go up to a speaker and be like, oh, I want to, like, dig into their talk a little bit. But I don't have anything to say other than just, like, "I liked your talk." So, if there's any sort of side trails I had to cut for the talk, I might give a shout-out to it and say, "Hey, if you want to learn more about this aspect, come talk to me afterwards." So, one thing that I put in this particular talk was like, "Hey, we're looking at these different graphical ways to think about time. These are similar to but not the same as thinking of time as a one-dimensional vector and applying vector math to it, which is a whole other side topic. If you want to nerd out about that, come find me in the hallway afterwards, and I'd love to go deeper on it." And yeah, some people did. STEPHANIE: That's really smart. I like that a lot. You're inviting more conversation about it, which I know, like, you also really enjoy just, like, taking it further or, like, caring about other people's experiences or their thoughts about vector math [laughs]. JOËL: I think it serves two purposes, right? It allows people to connect with me as a speaker. And it also allows me to feel better about pruning certain parts of my talk and saying, look, this didn't make sense to keep in the talk, but it's cool material. I'd love to have a continuing conversation about this. So, here's a path we could have taken. I'm choosing not to, as a speaker, but if you want to take that branch with me, let's have that afterwards in the hallway. STEPHANIE: Yeah. Or even as, like, new content for yourself or for someone else to take with them if they want to explore that further because, you know, there's always something more to explore [chuckles]. JOËL: I've absolutely done that with past talks. I've taken a thing I had to prune and turned it into a blog post. A recent example of that was when I gave a talk at RailsConf Portland, which I guess is not so recent. I was talking about ways to deal with a test suite that's making too many database requests. And talking about how sometimes misusing let in your RSpec tests can lead to more database requests than you expect. And I had a whole section about how to better understand what database requests will actually be made by a series of let expressions and dealing with the eager versus lazy and all of that. I had to cut it. But I was then able to make a blog post about it and then talk about this really cool technique involving dependency graphs. And that was really fun. So, that was a thing where I was able to say, look, here's some content that didn't make it into the talk because I needed to focus on other things. But as its own little, like, side piece of content, it absolutely works, and here's a blog post. STEPHANIE: Yeah. And then I think it turned into a Bike Shed episode, too [laughs]. JOËL: I think it did, yes. I think, in many ways, creativity begets creativity. It's hard to get started writing or producing content or whatever, but once you do, every idea you have kind of spawns new ideas. And then, pretty soon, you have a backlog that you can't go through. STEPHANIE: That's awesome. Any other highlights from the conference you want to shout out? JOËL: I'd love to give a shout-out to a couple of talks that I went to, Aji Slater's talk on the Enigma machine as a German code machine from World War II and how we can sort of implement our own in Ruby and an exploration of object-oriented programming was fantastic. Aji is just a masterful storyteller. So, that was really great. And then Alan Ridlehoover's talk on dealing with flaky tests that one, I think, was particularly useful because I think it's one of the talks that is going to be immediately relevant on Monday morning for, like, every developer that was in that room and is going back to their regular day job. And they can immediately use all of those principles that Alan talked about to deal with the flaky tests in their test suite. And there's, in particular, at the end of his presentation, Alan has this summary slide. He kind of broke down flakiness across three different categories and then talked about different strategies for identifying and then fixing tests that were flaky because of those reasons. And he has this table where he sort of summarizes basically the entire talk. And I feel like that's the kind of thing that I'm going to save as a cheat sheet. And that can be, like, I'm going to link to this and share it all over because it's really useful. Alan has already put his slides up online. It's all linked to that particular slide in the show notes because I think that all of you would benefit from seeing that. The talks themselves are recorded, but they're not going to be out for a couple of weeks. I'm sure when they do, we're going to go through and watch some and probably comment on some of the talks as well. So, Stephanie, what is new in your world? STEPHANIE: Yeah. So, I'm celebrating wrapping up a client project after a nine-month engagement. JOËL: Whoa, that's a pretty long project. STEPHANIE: Yeah, that's definitely on the longer side for thoughtbot. And I'm, I don't know, just, like, feeling really excited for a change, feeling really, you know, proud of kind of, like, all of the work that we had done. You know, we had been working with this client for a long time and had been, you know, continuing to deliver value to them to want to keep working with us for that long. But I'm, yeah, just looking forward to a refresh. And I think that's one of my favorite things about consulting is that, you know, you can inject something new into your work life at a kind of regular cadence. And, at least for me, that's really important in reducing or, like, preventing the burnout. So, this time around, I kind of started to notice, and other people, too, like my manager, that I was maybe losing a bit of steam on this client project because I had been working on it for so long. And part of, you know, what success at thoughtbot means is that, like, we as employees are also feeling fulfilled, right? And, you know, what are the different ways that we can try to make sure that that remains the case? And kind of rotating folks on different projects and kind of making sure that things do feel fresh and exciting is really important. And so, I feel very grateful that other people were able to point that out for me, too, when I wasn't even fully realizing it. You know, I had people checking in on me and being like, "Hey, like, you've been on this for a while now. Kind of what I've been hearing is that, like, maybe you do need something new." I'm just excited to get that change. JOËL: How do you find the balance between sort of feeling fulfilled and maybe, you know, finding that point where maybe you're feeling you're running out of steam–versus, you know, some projects are really complex, take a while to ramp up; you want to feel productive; you want to feel like you have contributed in a significant way to a project? How do you navigate that balance? STEPHANIE: Yeah. So, the flip side is, like, I also don't think I would enjoy having to be changing projects all the time like every couple of months. That maybe is a little too much for me because I do like to...on our team, Boost, we embed on our team. We get to know our teammates. We are, like, building relationships with them, and supporting them, and teaching them. And all of that is really also fulfilling for me, but you can't really do that as much if you're on more shorter-term engagements. And then all of that, like, becomes worthwhile once you're kind of in that, like, maybe four or five six month period where you're like, you've finally gotten your groove. And you're like, I'm contributing. I know how this team works. I can start to see patterns or, like, maybe opportunities or gaps. And that is all really cool, and I think also another part of what I really like about being on Boost. But yeah, I think what I...that losing steam feeling, I started to identify, like, I didn't have as much energy or excitement to push forward change. When you kind of get a little bit too comfortable or start to get that feeling of, well, these things are the way they are [laughs], -- JOËL: Right. Right. STEPHANIE: I've now identified that that is kind of, like, a signal, right? JOËL: Maybe time for a new project. STEPHANIE: Right. Like starting to feel a little bit less motivated or, like, less excited to push myself and push the team a little bit in areas that it needs to be pushed. And so, that might be a good time for someone else at thoughtbot to, like, rotate in or maybe kind of close the chapter on what we've been able to do for a client. JOËL: It's hard to be at 100% all the time and sort of always have that motivation to push things to the max, and yeah, variety definitely helps with that. How do you feel about finding signals that maybe you need a break, maybe not from the project but just in general? The idea of taking PTO or having kind of a rest day. STEPHANIE: Oh yeah. I, this year, have tried out taking time off but not going anywhere just, like, being at home but being on vacation. And that was really great because then it was kind of, like, less about, like, oh, I want to take this trip in this time of year to this place and more like, oh, I need some rest or, like, I just need a little break. And that can be at home, right? Maybe during the day, I'm able to do stuff that I keep putting off or trying out new things that I just can't seem to find the time to do [chuckles] during my normal work schedule. So, that has been fun. JOËL: I think, yeah, sometimes, for me, I will sort of hit that moment where I feel like I don't have the ability to give 100%. And sometimes that can be a signal to be like, hey, have you taken any time off recently? Maybe you should schedule something. Because being able to refresh, even short-term, can sort of give an extra boost of energy in a way where...maybe it's not time for a rotation yet, but just taking a little bit of a break in there can sort of, I guess, extend the time where I feel like I'm contributing at the level that I want to be. STEPHANIE: Yeah. And I actually want to point out that a lot of that can also be, like, investing in your life outside of work, too, so that you can come to work with a different approach. I've mentioned the month that I spent in the Hudson Valley in New York and, like, when I was there, I felt, like, so different. I was, you know, just, like, so much more excited about all the, like, novel things that I was experiencing that I could show up to work and be like, oh yeah, like, I'm feeling good today. So, I have all this, you know, energy to bring to the tasks that I have at work. And yeah, so even though it wasn't necessarily time off, it was investing in other things in my life that then brought that refresh at work, even though nothing at work really changed [laughs]. JOËL: I think there's something to be said for the sort of energy boost you get from novelty and change, and some of that you get it from maybe rotating to a different project. But like you were saying, you can change your environment, and that can happen as well. And, you know, sometimes it's going halfway across the country to live in a place for a month. I sometimes do that in a smaller way by saying, oh, I'm going to work this morning from a coffee shop or something like that. And just say, look, by changing the environment, I can maybe get some focus or some energy that I wouldn't have if I were just doing same old, same old. STEPHANIE: Yeah, that's a good point. So, one particularly surprising refresh that I experienced in offboarding from my client work is coming back to my thoughtbot, like, internal company laptop, which had been sitting gathering dust [laughs] a little bit because I had a client-issued laptop that I was working in most of the time. And yeah, I didn't realize how different it would feel. I had, you know, gotten everything set up on my, you know, my thoughtbot computer just the way that I liked it, stuff that I'd never kind of bothered to set up on my other client-issued laptop. And then I came back to it, and then it ended up being a little bit surprising. I was like, oh, the icons are smaller on this [laughs] computer than the other computer. But it definitely did feel like returning to home, I think, instead of, like, being a guest in someone else's house that you haven't quite, like, put all your clothes in the closet or in the drawers. You're still maybe, like, living out of a suitcase a little bit [laughs]. So yeah, I was kind of very excited to be in my own space on my computer again. JOËL: I love the metaphor of coming home, and yeah, being in your own space, sleeping in your own bed. There's definitely some of that that I feel, I think, when I come back to my thoughtbot laptop as well. Do you feel like you get a different sense of connection with the rest of our thoughtbot colleagues when you're working on the thoughtbot-issued laptop versus a client-issued one? STEPHANIE: Yeah. Even though on my client-issued computer I had the thoughtbot Slack, like, open on there so I could be checking in, I wasn't necessarily in, like, other thoughtbot digital spaces as much, right? So, our, like, project management tools and our, like, internal company web app, those were things that I was on less of naturally because, like, the majority of my work was client work, and I was all in their digital spaces. But coming back and checking in on, like, all the GitHub discussions that have been happening while I haven't had enough time to catch up on them, just realizing that things were happening [laughs] even when I was doing something else, that is both cool and also like, oh wow, like, kind of sad that I [chuckles] missed out on some of this as it was going on. JOËL: That's pretty similar to my experience. For me, it almost feels a little bit like the difference between back when we used to be in person because thoughtbot is now fully remote. I would go, usually, depending on the client, maybe a couple of days a week working from their offices if they had an office. Versus some clients, they would come to our office, and we would work all week out of the thoughtbot offices, particularly if it was like a startup founder or something, and they might not already have office space. And that difference and feeling the connection that I would have from the rest of the thoughtbot team if I were, let's say, four days a week out of a client office versus two or four days a week out of the thoughtbot office feels kind of similar to what it's like working on a client-issued laptop versus on a thoughtbot-issued one. STEPHANIE: Another thing that I guess I forgot about or, like, wasn't expecting to do was all the cleanup, just the updating of things on my laptop as I kind of had it been sitting. And it reminded me to, I guess, extend that, like, coming home metaphor a little bit more. In the game Animal Crossing, if you haven't played the game in a while because it tracks, like, real-time, so it knows if you haven't, you know, played the game in a few months, when you wake up in your home, there's a bunch of cockroaches running around [laughs], and you have to go and chase and, like, squash them to clean it up. JOËL: Oh no. STEPHANIE: And it kind of felt like that opening my computer. I was like, oh, like, my, like, you know, OS is out of date. My browsers are out of date. I decided to get an internal company project running in my local development again, and I had to update so many things, you know, like, install the new Ruby version that the app had, you know, been upgraded to and upgrade, like, OpenSSL and all of that stuff on my machine to, yeah, get the app running again. And like I mentioned earlier, just the idea of like, oh yeah, this has evolved and changed, like, without me [laughs] was just, you know, interesting to see. And catching myself up to speed on that was not trivial work. So yeah, like, all that maintenance stuff still got to do it. It's, like, the digital cleanup, right? JOËL: Exactly. So, you mentioned that on the client machine, you still had the thoughtbot Slack. So, you were able to keep up at least some messages there on one device. I'm curious about the experience, maybe going the other way. How much does thoughtbot stuff bleed into your personal devices, if at all? STEPHANIE: Barely. I am very strict about that, I think. I used to have Slack on my phone, I don't know, just, like, in an earlier time in my career. But now I have it a rule to keep it off. I think the only thing that I have is my calendar, so no email either. Like, that is something that I, like, don't like to check on my personal time. Yeah, so it really just is calendar just in case I'm, like, out in the morning and need to be, like, oh, when is my first meeting? But [laughs] I will say that the one kind of silly thing is that I also refuse to sign into my Google account for work. So, I just have the calendar, like, added to my personal calendar but all the events are private. So, I can't actually see what the events are [laughs]. I just know that I have something going on at, like, 10:00 a.m. So, I got to make sure I'm back home by then [laughs], which is not so ideal. But at the risk of being signed in and having other things bleed into my personal devices, I'm just living with that for now [laughs]. JOËL: What I'm hearing is that I could put some mystery events on your calendar, and you would have a fun surprise in the morning because you wouldn't know what it is. STEPHANIE: Yeah, that is true [laughs]. If you put, like, a meeting at, like, 8:00 a.m., [laughs] then I'm like, oh no, what's this? And then I arrive, and it's just, like [laughs], a fun prank meeting. So, you know, you were talking about how you were at the conference this week. And I'm wondering, how connected were you to work life? JOËL: Uh, not very. I tried to be very present in the moment at the conference. So, I'm, you know, connected to all the other thoughtboters who were there and connecting with the attendees. I do have Slack on my phone, so if I do need to check it for something. There was a little bit of communication that was going on for different things regarding the conference, so I did check in for that. But otherwise, I tried to really stay focused on the in-person things that are happening. I'm not doing any client work during those days that I'm at RubyConf, and so I don't need to deal with anything there. I had my thoughtbot laptop with me because that's what I used to give my presentation. But once the presentation was done, I closed that laptop and didn't open it again, and, honestly, that felt kind of good. STEPHANIE: Yeah, that is really nice. I'm the same way, where I try to be pretty connected at conferences, and, like, I will actually redownload Slack sometimes just for, like, coordinating purposes with other folks who are there. But I think I make it pretty clear that I'm, like, away. You know, like, I'm not actually...like, even though I'm on work time, I'm not doing any other work besides just being present there. JOËL: So, you mentioned the idea of work time. Do you have, like, a pretty strict boundary between personal time and work time and, like, try not to allow either to bleed into each other? STEPHANIE: Yeah. I can't remember if I've mentioned this on the show. I think I have, but I'm going to again because one of my favorite things that I picked up from The Bike Shed back when Chris Toomey and Steph Viccari were hosting the show is Chris had, like, a little ritual that he would do every day to signal that he was done with work. He would close his laptop and say, "Schedule shutdown complete," I think. And I've started adopting it because then it helps me be like, I'm not going to reopen my laptop after this because I have said the words. And even if I think of something that I maybe need to add to my to-do list, I will, instead of opening my computer and adding to my, like, whatever digital to-do list, I will, like, write it down on a piece of paper instead for the sake of, you know, not risking getting sucked back into, you know, whatever might be going on after the time that I've, like, decided that I need to be done. JOËL: So, you have a very strict divisioning between work time and personal time. STEPHANIE: Yeah, I would say so. I think it's important for me because even when I take time off, you know, sometimes folks might work a half day or something, right? I really struggle with having even a half day feel like, once I'm done with work, having that feel like okay, like, now I'm back in my personal time. I'd much prefer not working the entire day at all because that is kind of the only way that I can feel like I've totally reclaimed that time. Otherwise, it's like, once I start thinking about work stuff, it's like I need a mental boundary, right? Because if I'm thinking about a work problem, or, like, an interaction or, like, just anything, it's frustrating because it doesn't feel like time in my own brain [laughs] is my own. What do work and personal time boundaries look like for you? JOËL: I think it's evolved over time. Device usage is definitely a little bit more blurry for me. One thing that I have started doing since we've gone fully remote as the pandemic has been winding down and, you know, you can do things, but we're still working from home, is that more days than not, I work from home during the day, and then I leave my home during the evening. I do a variety of social activities. And because I like to be sort of present in the moment, that means that by being physically gone, I have totally disconnected because I'm not checking emails or anything like that. Even though I do have thoughtbot email on my phone, Gmail allows me to like log into my personal account and my thoughtbot account. I have to, like, switch between the two accounts, and so, that's, like, more work than I would want. I don't have any notifications come in for the thoughtbot account. So, unless I'm, like, really wanting to see if a particular email I'm waiting for has come in, I don't even look at it, ever. It's mostly just there in case I need to see something. And then, by being focused in the moment doing social things with other people, I don't find too much of a temptation to, like, let work life bleed into personal life. So, there's a bit of a physical disconnect that ends up happening by moving out of the space I work in into leaving my home. STEPHANIE: Yeah. And I'm sure it's different for everyone. As you were saying that, I was reminded of a funny meme that I saw a long time ago. I don't think I could find it if I tried to search for it. But basically, it's this guy who is, you know, sitting on one side of the couch, clearly working. And he's kind of hunched over and, like, typing and looking very serious. And then he, like, closes his laptop, moves over, like, just slides to the other side of the couch, opens his laptop. And then you see him, like, lay back, like, legs up on the coffee table. And it's, like, work computer, personal computer, but it's the same computer [laughs]. It's just the, like, how you've decided like, oh, it's time for, you know, legs up, Netflix watching [laughs]. JOËL: Yeah. Yeah. I'm curious: do you use your thoughtbot computer for any personal things? Or is it just you shut that down; you do the closing ritual, and then you do things on a separate device? STEPHANIE: Yeah, I do things on a separate device. I think the only thing there might be some overlap for are, like, career-related extracurriculars or just, like, development stuff that I'm interested in doing, like, separate from what I am paid to do. But that, you know, kind of overlaps a little bit because of, like, the tools and the stuff I have installed on my computer. And, you know, with our investment time, too, that ends up having a bit of a crossover. JOËL: I think I'm similar in that I'll tend to do development things on my thoughtbot machine, even though they're not necessarily thoughtbot-related, although they could be things that might slot into something like investment time. STEPHANIE: Yeah, yeah. And it's because you have all your stuff set up for it. Like, you're not [laughs] trying to install the latest Ruby version on two different machines, probably [laughs]. JOËL: Yeah. Also, my personal device is a Windows machine. And I've not wanted to bother learning how to set that up or use the Windows Subsystem for Linux or any of those tools, which, you know, may be good professional learning activities. But that's not where I've decided to invest my time. STEPHANIE: That makes sense. I had an interesting conversation with someone else today, actually, about devices because I had mentioned that, you know, sometimes I still need to incorporate my personal devices into work stuff, especially, like, two-factor authentication. And specifically on my last client project...I have a very old iPhone [laughs]. I need to start out by saying it's an iPhone 8 that I've had for, like, six or seven years. And so, it's old. Like, one time I went to the Apple store, and I was like, "Oh, I'm looking for a screen protector for this." And they're like, "Oh, it's an iPhone 8. Yikes." [laughs] This was, you know, like, not too long ago [laughs]. And the multi-factor authentication policy for my client was that, you know, we had to use this specific app. And it also had, like, security checks. Like, there's a security policy that it needed to be updated to the latest iOS. So, even if I personally didn't want to update my iOS [laughs], I felt compelled to because, otherwise, I would be locked out of the things that I needed to do at work [laughs]. JOËL: Yeah, that can be a challenge sometimes when you're adding work things to personal devices, maybe not because it's convenient and you want to, but because you don't have a choice for things like two-factor auth. STEPHANIE: Yeah, yeah. And then the person I was talking to actually suggested something I hadn't even thought about, which is like, "Oh, you know, if you really can't make it work, then, like, consider having that company issue another device for you to do the things that they're, like, requiring of you." And I hadn't even thought of that, so... And I'm not quite at the point where I'm like, everything has to be, like, completely separate [laughs], including two-factor auth. But, I don't know, something to consider, like, maybe that might be a place I get to if I'm feeling like I really want to keep those boundaries strict. JOËL: And I think it's interesting because, you know, when you think of the kind of work that we do, it's like, oh, we work with computers, but there are so many subfields within it. And device management and, just maybe, corporate IT, in general, is a whole subfield that is separate and almost a little bit alien. Two, I feel like me, as a software developer, I'm just aware of a little bit...like, I've read a couple of articles around...and this was, you know, years ago when the trend was starting called Bring Your Own Device. So, people who want to say, "Hey, I want to use my phone. I want to have my work email on my phone." But then does that mean that potentially you're leaking company memos and things? So, how do you secure that kind of thing? And everything that IT had to think through in order to allow that, the pros and cons. So, I think we're just kind of, as users of that system, touching the surface of it. But there's a lot of thought and discussion that, as an industry, the kind of corporate IT folks have gone through to struggle with how to balance a lot of those things. STEPHANIE: Yeah, yeah. I bet there's a lot of complexity or nuance there. I mean, we're just talking about, like, ways that we do or don't mix work and personal life. And for that kind of work, you know, that's, like, the job is to think really thoroughly about how people use their devices and what should and shouldn't be permissible. The last thing that I wanted to kind of ask about in terms of device management or, like, work and personal intermixing is the idea of being on call and your device being a way for work to reach you and that being a requirement, right? I feel very lucky to obviously not really be in that position. As consultants, like, we're not usually so embedded into a team that we're then brought into, like, an on-call rotation, and I think that's good for me. Like, I don't think that that is something I'd be interested in doing anytime soon. Do you have any experience with that? JOËL: I have not been on a project where I've had to be on call, and I think that's generally true for most of us at thoughtbot who are doing software development. I know those who are doing more kind of platformy SRE-type things are on call. And, in fact, we have specifically hired people in different regions around the world so that we can provide 24-hour coverage for that kind of thing. STEPHANIE: Yeah. And I imagine kind of like what we're talking about with work device management looks even different for that kind of role, where maybe you do need a lot more access to things, like, wherever you might be. JOËL: And maybe the answer there is you get issued a work-specific device and a work phone or something like that, or an old-school work pager. STEPHANIE: [laughs] JOËL: PagerDuty is not just a metaphoric thing. Back in the day, they used actual pagers. STEPHANIE: Yeah, that would be very funny. JOËL: So yeah, I can't speak to it from personal experience, but I could imagine that maybe some of the dynamics there might be a little bit different. And, you know, for some people, maybe it's fine to just have an app on your phone that pings you when something happens, and you have to be on call. And you're able to be present while waiting, like, in case you get pinged, but also let it go while you're on call. I can imagine that's, like, a really weird kind of, like, shadow, like, working, not working experience that I can't really speak to because I have not been in that position. STEPHANIE: Yeah. As you were saying that, I also had the thought that, like, our ability to step away from work and our devices is also very much dependent on, like, a company culture and those types of factors, right? Where, you know, it is okay for me to not be able to look at that stuff and just come back to it Monday morning, and I am very grateful [laughs] for that. Because I recognize that, like, not everyone is in that position where there might be a lot more pressure or urgency to be on top of that. But right now, for this time in my life, like, that's kind of how I like to work. JOËL: I think it kind of sits at the intersection of a few different things, right? There's sort of where you are personally. It might be a combination, like, personality and maybe, like, mental health, things like that, how you respond to how sharp or blurry those lines between work and personal life can be. Like you said, it's also an element of company culture. If there's a company culture that's really pushing to get into your personal life, maybe you need firmer boundaries. And then, finally, what we spent most of this episode talking about: technical solutions, whether that's, like, physically separating everything such that there are two devices. And you close down your laptop, and you're done for the day. And whether or not you allow any apps on your personal phone to carry with you after you leave for the day. So, I think at the intersection of those three is sort of how you're going to experience that, and every person is going to be a little bit different. Because those three...I guess I'm thinking of a Venn diagram. Those three circles are going to be different for everyone. STEPHANIE: Yeah, that makes complete sense. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Joël got to do some pretty fancy single sign-on work. And when it came time to commit, he documented the ridiculous number of redirects to give people a sense of what was happening. Stephanie has been exploring Rails callbacks and Ruby debugging tools, using methods like save_callbacks and Kernel.caller, and creating a function call graph to better understand and manage complex code dependencies. Stephanie is also engaged in an independent project and seeking strategies to navigate the challenges of solo work. She and Joël explore how to find external support and combat isolation, consider ways to stimulate creativity, and obtain feedback on her work without a direct team. Additionally, they ponder succession planning to ensure project continuity after her involvement ends. They also reflect on the unique benefits of solo work, such as personal growth and flexibility. Stephanie's focus is on balancing the demands of working independently while maintaining a connected and sustainable professional approach. ASCII Sequence Diagram Creator (https://textart.io/sequence) Callback debugging methods (https://andycroll.com/ruby/find-list-debug-active-record-callbacks-in-the-console/) Kernel.caller (https://ruby-doc.org/core-3.0.2/Kernel.html#method-i-caller) Method.source_location (https://ruby-doc.org/core-3.0.2/Method.html#method-i-source_location) Building web apps by your lonesome by Jeremy Smith (https://www.youtube.com/watch?v=Rr871vmV4YM) 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: I got to do something really fun this week, where I was doing some pretty fancy single sign-on work. And when it came time to commit, I wanted to document the kind of ridiculous number of redirects that happen and give people a sense of what was going on. And for my own self, what I had been doing is, I had done a sequence diagram that sort of shows, like, three different services that are all talking to each other and where they redirect to each other as they all go through the sequence to sign someone in. And I was like, how could I embed that in the commit message? Because I think it would be really useful context for someone trying to get an overview of what this commit is doing. And the answer, for me, was, can I get this sequence diagram in ASCII form somewhere? And I found a website that allows me to do this in ASCII art. It's the textart.io/sequence. And that allows me to create a sequence diagram that gets generated as ASCII art. I can copy-paste that into a commit message. And now anybody else who is like, "What is it that Joël is trying to do here?" can look at that and be like, "Oh, oh okay, so, we got these, like, four different places that are all talking to each other in this order. Now I see what's happening." STEPHANIE: That's super neat. I love the idea of having it directly in your commit message just because, you know, you don't have to go and find a graph elsewhere if you want to understand what's going on. It's right there for you, for future commit explorers [laughs] trying to understand what was going on in this snippet of time. JOËL: I try as much as possible to include those sorts of things directly in the commit message because you never know who's reading the commit. They might not have access to some sort of linked resource. So, if I were like, "Hey, go to our wiki and see this link," like, sure, that would be helpful, but maybe the person reading it doesn't have access to the wiki. Maybe they do have access, but they're not on the internet right now, and so they don't have access to the wiki. Maybe the wiki no longer exists, and that's a dead link. So, as much as possible, I try to embed context directly in my commit messages. STEPHANIE: That's really cool. And just another shout out to ASCII art, you know [laughs], persevering through all the times with our fancy tools. It's still going strong [laughs]. JOËL: Something about text, right? STEPHANIE: Exactly. I actually also have a diagram graph thing to share about what's new in my world that is kind of in a similar vein. Another thoughtboter and former guest on the show, Sara Jackson, shared in our dev channel about this really cool mural graph that she made to figure out what was going on with callbacks because she was working on, you know, understanding the lifecycle of this model and was running into, like, a lot of complex behavior. And she linked to a really neat blog post by Andy Croll, too, that included a little snippet sharing a few callback debugging methods that are provided by ActiveRecord. So, basically, you can have your model and just call double underscore callbacks. And it returns a list of all the callbacks that are defined for that model, and I thought that was really neat. So, I played around with it and copypastad [laughs] the snippet into my Rails console to figure out what's going on with basically, like, the god object of that that I work in. And the first issue I ran into was that it was undefined because it turns out that my application was on an older [laughs] version of Rails than that method was provided on. But, there are more specific methods for the types of callbacks. So, if you are looking specifically for all the callbacks related to a save or a destroy, I think it's save underscore callbacks, right? And that was available on the Rails version I was on, which was, I think, 4. But that was a lot of fun to play around with. And then, I ended up chatting with Sara afterwards about her process for creating the diagram after, you know, getting a list of all these methods. And I actually really liked this hybrid approach she took where, you know, she automated some parts but then also manually, like, went through and stepped through the code and, like, annotated notes for the methods as she was traversing them. And, you know, sometimes I think about, like, wow, like, it would be so cool if this graph just generated automatically, but I also think there is some value to actually creating it yourself. And there's some amount of, like, mental processing that happens when you do that, as opposed to, like, looking at a thing that was just, you know, generated afterwards, I think. JOËL: Do you know what kind of graph Sara generated? Was it some kind of, like, function call graph, or was it some other way of visualizing the callbacks? STEPHANIE: I think it was a function call graph, essentially. It even kind of showed a lot of the dependencies, too, because some of the callback functions were quite complicated and then would call other classes. So, there was a lot of, I think, hidden dependencies there that were unexpected, you know, when you think you're just going to create a regular old [laughs] record. JOËL: Yeah, I've been burned by unexpected callbacks or callbacks that do things that you wouldn't want in a particular context and then creating bad data or firing off external services that you really didn't want, and that can be an unpleasant surprise. I appreciate it when the framework offers debugging tools and methods kind of built-in, so these helpers, which I was not aware of. It's really cool because they allow you to kind of introspect and understand the code that you're going through. Do you have any others like that from Rails or Ruby that you find yourself using from time to time to help better understand the code? STEPHANIE: I think one I discovered recently was Kernel.caller, which gives you the stack trace wherever you are when executing. And that was really helpful when you're not raising an exception in certain places, and you need to figure out the flow of the code. I think that was definitely a later discovery. And I'm glad to have it in my back pocket now as something I can use in any kind of Ruby code. JOËL: That can, yeah, definitely be a really useful context to have even just in, like, an interactive console. You're like, wait a minute, where's this coming from? What is the call stack right now? STEPHANIE: Do you have any debugging tools or methods that you like to use that maybe are under the radar a little bit? JOËL: One that I really appreciate that's built into Ruby is the source location method on the method object, so Ruby has a method object. And so, when you're dealing with some sort of method and, like, maybe it got generated programmatically through metaprogramming, or maybe it's coming from a gem or something like that, and you're just like, where is this define? I'm trying to find it. If you're in your editor and you're doing stuff, maybe you could run some sort of search, or maybe it has some sort of keyword lookup where you can just find the definition of what's under your cursor. But if you're in an interactive console, you can create a method object for that method name and then call dot source location on it. And it will tell you, here's where it's defined. So, very handy in the right circumstances. STEPHANIE: Awesome. That's a great tip. JOËL: Of course, one of the most effective debugging tools is having a pair, having somebody else work with you, but that's not always something that you have. And you and I were talking recently about what it's like to work solo on a project. Because you're currently on a project, you're solo, at least from the thoughtbot side of things. You're embedding with a team, with a client. Are you working on kind of, like, a solo subtask within that, or are you still kind of embedding and interacting with the other teammates on a regular basis? STEPHANIE: Yeah. So, the past couple of weeks, I am working on more of a solo initiative. The other members of my client team are kind of ramping up on some other projects for this next quarter. And since my engagement is ending soon, I'm kind of left working on some more residual tasks by myself. And this is new for me, actually. I've not really worked in a super siloed by-myself kind of way before. I usually have at least one other dev who I'm, like, kind of partnering up with on a project, or an epic, or something like that. And so, I've had a very quiet week where no one is, you know, kind of, like, reaching out to me and asking me to review their code, or kind of checking in, or, you know, asking me to check in with them. And yeah, it's just a little bit different than how I think I like to normally work. I do like to work with other people. So, this week has been interesting in terms of just kind of being a more different experience where I'm not as actively collaborating with others. JOËL: What do you think are some of the biggest challenges of being kind of a little bit out in your own world? STEPHANIE: I think the challenges for me can definitely be the isolation [laughs], and also, what kind of goes hand in hand with that is when you need help, you know, who can you turn to? There's not as much of an obvious person on your team to reach out to, especially if they're, like, involved with other work, right? And that can be kind of tough. Some of the other ones that I've been thinking about have been, you know, on one hand, like, I get to make all of the decisions that I want [laughs], but sometimes you kind of get, like, really in your own head about it. And you're not in that space of, like, evaluating different solutions that you maybe might not think of. And I've been trying to figure out how to, like, mitigate some of that risk. JOËL: What are some of the strategies that you use to try to balance, like making good decisions when you're a bit more solo? Do you try to pull in someone from another team to talk ideas through? Do you have some sort of internal framework that you use to try to figure out things on your own? What does that look like? STEPHANIE: Yeah, luckily, the feature I'm working on is not a huge project. Well, if it were, I think then I wouldn't be alone on it. But, you know, sometimes you find yourself kind of tasked with one big thing for a while, and you are responsible for from start to finish, like all of the architectural decisions to implementation. But, at least for me, the scope is a little more narrow. And so, I don't feel as much of a need to get a lot of heads together because I at least feel somewhat confident in what I'm doing [laughs]. But I have found myself being a bit more compelled to kind of just verbalize what I'm doing more frequently, even to, like, myself in Slack sometimes. It's just like, I don't know who's reading this, but I'm just going to put it out there because maybe someone will see this and jump in and say, "Oh, like, interesting. Here's some other context that I have that maybe might steer you away from that," or even validating what I have to say, right? Like, "That sounds like a good idea," or, you know, just giving me an emoji reaction [laughs] is sometimes all I need. So, either in Slack or when we give our daily sync updates, I am, I think, offering a little more details than I might if I already was working with someone who I was more in touch with in an organic way. JOËL: And I think that's really powerful because it benefits you. Sort of by having to verbalize that or type it out, you, you know, gain a little bit of self-awareness about what you're trying to do, what the struggles are. But also, it allows anybody else who has potentially helpful information to jump in. I think that's not my natural tendency. When I'm on something solo, I tend to kind of, like, zoom in and focus in on something and, like, ignore a little bit of the world around me. Like, that's almost the time when I should look at overcommunicating. So, I think most times I've been on something solo, I sort of keep relearning this lesson of, like, you know, it's really important to constantly be talking out about the things that you're doing so that other people who are in a broader orbit around you can jump in where necessary. STEPHANIE: Yeah, I think you actually kind of touched on one of the unexpected positives, at least for me. Something I wasn't expecting was how much time I would have to just be with my thoughts. You know, as I'm implementing or just in my head, I'm mulling over a problem. I have less frequent, not distractions necessarily, but interruptions. And sometimes, that has been a blessing because I am not in a spot where I have a lot of meetings right now. And so, I didn't realize how much generative thought happens when you are just kind of, like, doing your own thing for a little bit. I'm curious, for you, is that, like, a space that you enjoy being when you're working by yourself? And I guess, you know, you were saying that it's not your natural state to kind of, like, share what's going on until maybe you've fully formed an idea. JOËL: I think I often will regret not having shared out before everything is done. The times that I have done it, I've been like, that was a really positive experience; I should do that more. I think it's easy to sort of wait too long before sharing something out. And with so many things, it feels like there's only one more small task before it's done. Like, I just need to get this one test to go green, and then I can just put up a PR, and then we'll have a conversation about it. But then, oh, this other test broke, or this dependency isn't installing correctly. And before you know it, you've spent a whole day chasing down these things and still haven't talked. And so, I think if some of those things were discussed earlier, it would help both to help me feel more plugged in, but also, I think everybody else feels like they're getting a chance to participate as well. STEPHANIE: So, you mentioned, you know, obviously, there's, like, the time spent just arriving at the solution before sharing it out for feedback. But have you ever been in a position where there is no one to give you feedback and, like, not even a person to review your code? JOËL: That's really challenging. So, occasionally, if I'm working on a project, maybe it would be, like, very early-stage startup that maybe just has, like, a founder, and then I'm, like, the only technical person on the team, generally, what I'll try to do is to have some kind of review buddy within thoughtbot, so some other developer who's not staffed on my project but who has access to the code such that I can ask them to say, "Hey, can you just take a look at this and give me a code review?" That's the ideal situation. You know, some companies tend to lock things down a lot more if you're dealing with something like healthcare or something like that, where there might be some concerns around personal information, that kind of thing. But generally, in those cases, you can find somebody else within the company who will have some technical knowledge who can take a look at your code; at least, that's been my experience. STEPHANIE: Nice. I don't think I've quite been in that position before; again, I've really mostly worked within a team. But there was a conference talk I watched a little bit ago from Jeremy Smith, and it was called Building Web Apps by Your Lonesome. And he is a, like, one-man agency. And he talked about, you know, what it's like to be in that position where you pretty much don't have other people to collaborate with, to review your code. And one thing that he said that I really liked was shifting between writer and editor mode. If you are the person who has to kind of just decide when your code is good enough to merge, I like that transition between, like, okay, I just spent however many hours putting together the solution, and now I'm going to look at it with a critical eye. And sometimes I think that might require stepping away for a little bit or, like, revisiting it even the next day. That might be able to help see things that you weren't able to notice when you were in that writing mode. But I have found that distinction of roles really helpful because it does feel different when you're looking at it from those two lenses. JOËL: I've definitely done that for some, like, personal solo projects, where I'm participating in a game jam or something, and then I am the only person to review my code. And so, I will definitely, at that point, do a sort of, like, personal code review where I'll look at it. Maybe I'm doing PRs on GitHub, and I'm just merging. Maybe I'm just doing a git diff and looking at a commit in the command line on my own machine. But it is useful, even for myself, to sort of switch into that editor mode and just kind of look at everything there and say, "Is it in a good place?" Ideally, I think I do that before putting it out for a co-worker's review, so you kind of get both. But on a solo project, that has worked actually pretty well for me as well. STEPHANIE: One thing that you and I have talked about before in a different context, I think, when we have chatted about writing conference talks, is you are really great about focusing on the audience. And I was thinking about this in relation to working solo because even when you are working by yourself on a project, you're not writing the code for yourself, even though you might feel like [laughs] it in the moment. And I also kind of like the idea of asking, like, who are you building for? You know, can you ask the stakeholder or whoever has hired you, like, "Who will maintain this project in the future?" Because likely, it won't be you. Hopefully, it won't be you unless that's what you want to be doing. There's also what my friend coined the circus factor as opposed to the bus factor, which is, like, if you ran away to the circus tomorrow [laughs], you know, what is the impact that would have? And yeah, I think working solo, you know, some people might think, like, oh, that gives me free rein to just write the code exactly how I want to, how I want to read it. But I think there is something to be said about thinking about the future of who will be [inaudible 18:10] what you just happen to be working on right now. JOËL: And keep in mind that that person might be future you who might be coming back and be like, "What is going on here?" So, yeah, audience, I think, is a really important thing to keep in mind. I like to ask the question, if somebody else were looking at this code, and somebody else might be future me, what parts would they be confused by? If I was walking somebody else through the code for the first time, where would they kind of stop me through the walkthrough and be like, "Hey, why is this happening? What's the connection between these two things? I can see they're calling each other, but I don't know why." And that's where maybe you put in a comment. Maybe you find a better method or a class name to better explain what happens. Maybe you need to put more context in a commit message. There's all sorts of tools that we can use to better increase documentation. But having that pause and asking, "What will confuse someone?" is, I think, one of the more powerful techniques I do when I'm doing self-review. STEPHANIE: That's really cool. I'm glad you mentioned that, you know, it could also be future you. Because another thing that Jeremy says in this talk that I was just thinking about is the idea of optimizing for autonomy. And there's a lot to be said there because autonomy is like, yeah, like, you end up being the person who has to deal with problems [laughs], you know, if you run into something that you can't figure out, and, ideally, you'll have set yourself up for success. But I think working solo doesn't mean that you are in your own universe by yourself completely. And thinking about future, you, too, is kind of, like, part of the idea that the person in this moment writing code will change [laughs]. You'll get new information. Maybe, like, you'll find out about, like, who might be working on this in the future. And it is kind of a fine balance between making sure that you're set up to handle problems, but at the same time, maybe it's that, like, you set anyone up to be able to take it away from where you left it. JOËL: I want to take a few moments to sort of talk a little bit about what it means to be solo because I think there are sort of multiple different solo experiences that can be very different but also kind of converge on some similar themes. Maybe some of our listeners are listening to us talking and being like, "Well, I'm not at a consultancy, so this never happens to me." But you might find yourself in that position. And I think one that we mentioned was maybe you are embedded on a team, but you're kind of on a bit of a larger project where you're staffed solo. So, even though you are part of a larger team, you do feel like the initiative that you're on is siloed to you a little bit. Are there any others that you'd like to highlight? STEPHANIE: I think we also mentioned, you know, if you're a single developer working on an application because you might be the first technical hire, or a one-person agency, or something, that is different still, right? Because then your community is not even your company, but you have to kind of seek out external communities on social networks, or Slack groups, or whatever. I've also really been interested in the idea of developers kind of being able to be rotated with some kind of frequency where you don't end up being the one person who knows everything about a system and kind of becomes this dependency, right? But how can we make projects so, like, well functioning that, like, anyone can step in to do some work and then move on? If that's just for a couple of weeks, for a couple of months. Do you have any thoughts about working solo in that kind of situation where you're just stepping into something, maybe even to help someone out who's, you know, on vacation, or kind of had to take an unexpected leave? JOËL: Yeah, that can be challenging. And I think, ideally, as a team, if you want to make that easier, you have to set up some things both on a, like, social level and on a tactical level, so all the classic code quality things that you want in place, well structured, encapsulated code, good documentation, things like that. To a certain extent, even breaking down tasks into smaller sort of self-sufficient stories. I talk a lot about working incrementally. But it's a lot easier to say, "Hey, we've got this larger story. It was broken down into 20 smaller pieces that can all be shipped independently, and a colleague got three of them done and then had to go on leave for some reason. Can you step in and do stories 4 through 20?" As opposed to, "Hey, we have this big, amorphous story, and your colleague did some work, and it kind of is done. There's a branch with some code on it. They left a few notes or maybe sent us an email. But they had to go on leave unexpectedly. Can you figure it out and get it done?" The second scenario is going to be much more challenging. STEPHANIE: Yeah, I was just thinking about basically what you described, right? Where you might be working on your own, and you're like, well, I have this one ticket, and it's capturing everything, and I know all that's going on [laughs], even though it's not quite documented in the ticket. But it's, you know, maybe on my branch, or in my head, or, worst of all, on my local machine [laughs] without being pushed up. JOËL: I think maybe that's an anti-pattern of working solo, right? A lot of these disciplines that you build when you're working in a team, such as breaking up tickets into smaller pieces, it's easy to kind of get a little bit lazy with them when you're working solo and let your tickets inflate a little bit, or just have stuff thrown together in branches on your local machine, which then makes it harder if somebody does need to come in to either collaborate with you or take over from you if you ever need to step aside. STEPHANIE: Right. I have definitely seen some people, even just for their personal projects, use, like, a Trello board or some other project management tool. And I think that's really neat because then, you know, obviously, it's maybe just for their own, like, self-organization needs, but it's, like, that recognition that it's still a complicated project. And just because they're working by themselves doesn't mean that they can't utilize a tool for project management that is meant for teams or not even teams [laughs], you know, people use them for their own personal stuff all the time. But I really like that you can choose different levels of how much you're documenting for your future self or for anyone else. You had mentioned earlier kind of the difference between opening up a PR for you...you have to merge your branch into main or whatever versus just committing to main. And that distinction might seem, like, if you were just working on a personal project, like, oh, you know, why go through the extra step? But that can be really valuable in terms of just seeing, like, that history, right? JOËL: I think on solo projects, it can really depend on the way you tend to treat your commit history. I'm very careful with the history on the main branch where I want it to tell a sort of, like, cohesive story. Each commit is kind of, like, crafted a little bit. So, even when I'm working solo and I'm committing directly to master or to the main branch, I'm not just, like, throwing random things there. Ideally, every commit is green and builds and is, like, self-contained. If you don't have that discipline, then it might be particularly valuable to go through the, like, a branching system or a PR system. Or if you just want, like, a place to experiment, just throw a bunch of code together, a bunch of things break; nothing is cohesive, that's fine. It's all a work in progress until you finally get to your endpoint, and then you squash it down, or you merge it, or whatever your workflow is, and then it goes back into the main branch. So, I think that for myself, I have found that, oftentimes, I get not really a whole lot of extra value by going through a branching and PR system when it's, like, a truly solo project, you know, I'm building a side project, something like that. But that's not necessarily true for everyone. STEPHANIE: I think one thing I've seen in other people's solo projects is using a PR description and, you know, having the branching strategy, even just to jot down future improvements or future ideas that they might take with the work, especially if you haven't kind of, like, taken the next step of having that project management system that we talked about. But there is, like, a little more room for some extra context or to, like, leave yourself little notes that you might not want necessarily in your commit history but is maybe more related to this project being, like, a work in progress where it could go in a lot of different directions, and you're figuring that out by yourself. JOËL: Yeah, I mean, definitely something like a draft PR can be a great place to have work in progress and experiment and things like that. Something you were saying got me wondering what distinction you typically have between what you would put in a commit message versus something that you would put in a PR description, particularly given that if you've got, like, a single commit PR, GitHub will automatically make the commit message your PR message as well. STEPHANIE: This has actually evolved for me over time, where I used to be a lot more reliant on PR descriptions holding a lot of the context in terms of the decision-making. I think that was because I thought that, like, that was the most accessible place of information for reviewers to find out, you know, like, why certain decisions were made. And we were using, you know, PR templates and stuff like that. But now the team that I'm working on uses commit message templates that kind of contain the information I would have put in a PR, including, like, motivation for the change, any risks, even deployment steps. So, I have enjoyed that because I think it kind of shortens the feedback loop, too, right? You know, you might be committing more frequently but not, you know, opening a PR until later. And then you have to revisit your commits to figure out, like, okay, what did I do here? But if you are putting that thought as soon as you have to commit, that can save you a little bit of work down the line. What you said about GitHub just pulling your commit message into the PR description has been really nice because then I could just, like, open a thing [laughs]. And that has been nice. I think one aspect that I really like about the PR is leaving myself or reviewers, like, notes via comments, like, annotating things that should not necessarily live in a more permanent form. But maybe I will link to documentation for a method that I'm using that's a little less common or just add some more information about why I made this decision over another at a more granular level. JOËL: Yeah, I think that's probably one of the main things that I tend to put in a PR message rather than the commit message is any sort of extra information that will be helpful at review time. So, maybe it's a comment that says, "Hey, there is a lot of churn in this PR. You will probably have a better experience if you review this in split view versus unified view," things like that. So, kind of, like, meta comments about how you might want to approach reviewing this PR, as opposed to something that, let's say somebody is reviewing the history or is, like, browsing the code later, that wouldn't be relevant to them because they're not in a code review mindset. They're in a, like, code reading, code understanding mindset or looking at the message to say, "Why did you make the changes? I saw this weird method. Why did you introduce that?" So, hopefully, all of that context is in the commit message. STEPHANIE: Yeah, you reminded me of something else that I do, which is leave notes to my future self to revisit something if I'm like, oh, like, this was the first idea I had for the, you know, the way to solve this problem but, you know, note to self to look at this again tomorrow, just in case I have another idea or even to, like, you know, do some more research or ask someone about it and see if they have any other ideas for how to implement what I was aiming for. And I think that is the editor mode that we were talking about earlier that can be really valuable when you're working by yourself to spend a little extra time doing. You know, you are essentially optimizing for autonomy by being your own reviewer or your own critic in a healthy and positive way [laughs], hopefully. JOËL: Exactly. STEPHANIE: So, at the beginning of this episode, I mentioned that this is a new experience for me, and I'm not sure that I would love to do it all of the time. But I'm wondering, Joël, if there are any, you know, benefits or positives to working solo that you enjoy and find that you like to do just at least for a short or temporary amount of time. JOËL: I think one that I appreciate that's maybe a classic developer response is the heads downtime, the focus, being able to just sit down with a problem and a code editor and trying to figure it out. There are times where you really need to break out of that. You need somebody else to challenge you to get through a problem. But there are also just amazing times where you're in that flow state, and you're getting things done. And that can be really nice when you're solo. STEPHANIE: Yeah, I agree. I have been enjoying that, too. But I also definitely am looking forward to working with others on a team, so it's kind of fun having to get to experience both ways of operating. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeeeeee!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Stephanie is engrossed in Kent Beck's Substack newsletter, which she appreciates for its "working thoughts" format. Unlike traditional media that undergo rigorous editing, Kent's content is more of a work-in-progress, focusing on thought processes and evolving ideas. Joël has been putting a lot of thought into various tools and techniques and realized that they all fall under one umbrella term: analysis. From there, Stephanie and Joël discuss all the productivity tricks they like to use in their daily workflows. Do you have some keyboard shortcuts you like? Are you an Alfred wizard? What are some tools or mindsets around productivity that make YOUR life better? Kent Beck's Substack Tidy First? (https://tidyfirst.substack.com/) Debugging: Listing Your Assumptions (https://thoughtbot.com/blog/debugging-listing-your-assumptions) Dash (https://kapeli.com/dash) Alfred (https://www.alfredapp.com/) Rectangle (https://rectangleapp.com/) Meeter (https://apps.apple.com/us/app/meeter-for-zoom-teams-co/id1510445899) Vim plugins (https://github.com/thoughtbot/dotfiles/blob/main/vimrc.bundles#L32-L50) from thoughtbot's dotfiles, including vim-projectionist () for alternate files Go To Spec VS Code plugin (https://marketplace.visualstudio.com/items?itemName=Lourenci.go-to-spec) Feedbin (https://feedbin.com/) Energy Makes Time by Mandy Brown (https://everythingchanges.us/blog/energy-makes-time/) Transcript: AD: Ruby developers, The Rocky Mountain Ruby Conference returns to Boulder, Colorado, on October 5th and 6th. Join us for two days of insightful talks from experienced Ruby developers and plenty of opportunities to connect with your Ruby community. But that's not all. Nestled on the edge of the breathtaking Rocky Mountains, Boulder is a haven for outdoor lovers of all stripes. Take a break from coding. Come learn and enjoy at the conference and explore the charm of Downtown Boulder: eclectic shops, first-class restaurants and bars, and incredible street art everywhere. Immerse yourself in the vibrant culture and the many microbrew pubs that Boulder has to offer. Grab your tickets now at rockymtnruby.dev and be a part of the 2023 Rocky Mountain Ruby Conference. That's rockymtnruby.dev, October 5th and 6th in Boulder. See you there. 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 have a new piece of content that I'm consuming lately. That is Kent Beck's Substack [chuckles], Kent Beck of Agile Manifesto and Extreme Programming notoriety. I have been really enjoying this trend of independent content creation in the newsletter format lately, and I subscribe to a lot of newsletters for things outside of work as well. I've been using an RSS feed to like, keep track of all of the dispatches I'm following in that way so that it also kind of keeps out of my inbox. And it's purely just for when I'm in an internet-reading kind of mood. But I subscribed to Kent's Substack. Most of his content is behind a subscription. And I've been really enjoying it because he treats it as a place for a lot of his working thoughts, kind of a space that he uses to explore topics that could be whole books. But he is still in the phase of kind of, like, thinking them through and, like, integrating, you know, different things he's learning, and acknowledging that, like, yeah, like, not all of these ideas are fully fleshed, but they are still worth publishing for people who might be interested in kind of his thought process or where his head is at. And I think that is really cool and very different from just, like, other types of content I consume, where there has been, like, a lot of, especially more traditional media, where there has been, like, more editing involved and a lot of time and effort to reach a final product. And I'm curious about this, like I mentioned, trend towards a little less polished and people just publishing things as they're working through them and acknowledging that the way they're thinking about things can change over time. JOËL: It sounds like this is kind of halfway between a book which has gone through a lot of editing and, you know, a tweet thread, which is pure stream of consciousness. STEPHANIE: Yeah, that's a really great insight, actually. And I think that might be my sweet spot in terms of things I enjoy consuming or reading because I like that room for change and that there is a bit of a, you know, community aspect to Substack where you can comment on posts. But, at least in my experience, has seemed, like, relatively healthy because it is, you know, you're kind of with a community of people who are at least invested or willing to pay [chuckles] for the content. So, there is some amount of good faith involved. His newsletter title itself it's called "Tidy First?" And so, that almost implies that it's, like, something he's still exploring or experimenting with, which I think is really cool. It's not like a I have discovered, like, the perfect way to do things, and, you know, you must always tidy first before you do your software development. He's kind of in the position of, this is what I think works, and this is my space for continuing to refine this idea. JOËL: I'm curious: are there any sort of articles that you've read or just thoughts in general that you've seen from Kent that are particularly impactful or memorable to you? STEPHANIE: Yeah. One I read today during my investment time is called Accountability in Software Development. And it was a very interesting take on the idea of accountability, not necessarily, like, when it's forced by others or external forces like a manager or, you know, your organization, but when it comes from yourself. And he describes it as a way to feel comfortable and confident in the work that he's doing and also building trust in himself and in his work but also in his teams. By being transparent and literally accounting for the things that he's doing and sharing them, communicating them publicly, that almost ends up diminishing any kind of, like, distrust, or shame, or any of those weird kind of squishy things that can happen when you hide those things or, like, hide what you're doing. It becomes a way to foster the good parts of working with other people but not in a necessarily like, resentful way or in a hierarchical way. I was really interested in the idea of accountability, ultimately, like, for yourself, and then that ends up just propagating to the team. JOËL: That's a really interesting topic because I think it sort of sits at the intersection of the personal and the technical. STEPHANIE: Yeah, absolutely. He mentions more technical strategies or tasks that kind of do the same thing. You know, he mentions test-driven development, as well as, like, a way of holding yourself accountable to writing software that, you know, doesn't have bugs in it. So, I think that it can be applied to, you know, exactly both of those, like, interpersonal stuff and also technical aspects too, anyway, that's what's new in my world. Joël, what about you? JOËL: So, this year, I've been putting a lot of thought into a variety of tools and processes. And I think I've come to the realization that they all really fall under one kind of umbrella term, and that would be analysis. It's a common step in some definitions of the traditional software development lifecycle. And it's where you try to after you've kind of gathered the requirements, try to break them down and understand what exactly that means from a technical perspective, what needs to happen. And so, a lot of the things that have been really fascinating to me this year have been different techniques that I can use to become better at that sort of phase. STEPHANIE: Wow. That's very powerful, I think. And honestly, the first thing that comes to mind is, how do you make time for it? JOËL: I think we all do it to a certain extent. You know, you pick up a ticket, and there is a prose description of some work to be done, hopefully not telling you directly, like, just go make a change to this class, but here's a business problem to be solved. And then you have to sort of figure out how to break it down. So, this can be as simple as, oh, what objects, what classes do I need to introduce for this change? But it might be more subtle in terms of thinking, okay, well, what are the edge cases I need to think about? Where are things that could fail, and how am I going to handle failure? So, there's a variety of techniques that you can use to get better at all of these. You can use them kind of at the micro level when thinking about just a ticket. You can use them when working on a larger epic, a larger initiative, a whole project because I think analysis fits into kind of all of these levels. And so, I think those are the techniques that have been most exciting to me this year and that have really connected. STEPHANIE: That is very exciting. It's triggering a lot of thoughts for me about how I incorporate analysis into my work and how that has actually evolved; where I think before, earlier in my career, I assumed that the analysis had been done by someone else who knew better than me or who knew more than me. And that by the time that you know, a piece of work kind of landed in my lap, I was like, okay, well, I just want to know what to do, right? Like, I want someone else to tell me what to do [laughs]. But now I think I have taken it upon myself to do more of that and, like, have realized that it's part of my role. And sometimes it will now be kind of a flag or, like, a signal to me when that hasn't been done. And I can tell when I receive a ticket, and it's, like, maybe missing the business problem or doesn't have enough information. And determining whether that is information that I need to go and find out, or if there's someone else who I can work together with to do that analysis with, or having a better understanding of, like, what is within my realm of analysis to do, and what I need to encourage other people to do analysis for before the work is ready for me. JOËL: I think there is an interesting distinction between more traditional requirements gathering and analysis, where traditional requirements gathering is getting all that business problem information from product people, from customers, things like that. The analysis step is often a little bit more about breaking down a business problem into, like, what are the technical ramifications of that? But there can be a little of a synergy there where sometimes, once you start exploring the technical side of it, it might bring up a lot of edge cases that have impacts on the product side, on the business side. And then you have to go back to the businesspeople and say, "Hey, we only talked about sort of the happy path. What happens if payment is declined? What do we want to do there?" And now we're back in sort of that requirements gathering phase a little bit more rather than purely analysis. But it can come out of an analysis phase where you've done maybe some state machine diagramming to try to better understand how things flow from one phase to another. Or maybe you were building out a truth table for some complex logic and realized, wait a minute, there's an edge case I didn't handle. It's not a strictly linear process. The two kind of feed into each other and, honestly, into the implementation side as well. STEPHANIE: Yeah, I'm with you there. I'm thinking about a piece of work that I've been working on, where we were thinking of doing a database migration and adding some new columns to a table. But the more I dug into it, the more I realized that that was the first idea or the immediate idea that came from a need that I had limited information about. And what was nice was I was able to sit on it for a little bit, get some input from others. And I realized that there were all of these things that I couldn't answer yet. And someone, I think literally asked in a code review if you've already done this analysis, between knowing that these columns will be the kind of extent of what you need versus, you know, will the data end up needing more columns? And should the data model be a little more flexible to that potential change? And they said, "If you had already done this analysis, then, like, otherwise, it looks good to me." And I was like, "Oh, I didn't." [laughs] And that encouraged me to go back to some cross-functional members of the team and ask more questions. And that has taken more time. That was another challenge that I had to encounter was saying like, "Yeah, we started this, and we made some progress. But actually, we need to revisit a few things, like a few parts of the premise, before continuing on." JOËL: Are there any techniques or approaches that you particularly enjoy when it comes to doing an analysis or that maybe are go-to's for you? STEPHANIE: Reminding myself to revisit my assumptions [laughs], or at least even starting by being really clear about what I'm assuming, right? Because I think that has to happen first before you can even revisit them is having an awareness of what assumptions you're making. And I actually think this is where collaboration has been really helpful, where I've been working on this task with another developer on my team. And when we've been talking about it, I found myself saying, "Oh, I'm assuming this," right? Or, like, I'm assuming that the stakeholder knows what they need [laughs]. And that's why we're going to do it this way, where we were kind of given the pieces of data that we should be persisting. And the more that we had that conversation, the more I realized, like, actually, like, I'm not convinced that they have that full picture of, like, what they need in the future. And because we're making this decision now, like, we are turning, you know, literally from, like, the abstract into, like, a concrete change [chuckles] in the database, now seems like...now that we're faced with that decision, it seems like a good time to revisit the assumption that I was making. And that has proved helpful in making ultimately, like, a more informed decision about, like, which way to go technically. But I personally have found a lot of value in verbally processing it with someone else. It's a lot harder for me to identify them, I think, when I'm in my own head. JOËL: That's really interesting that you keyed in on the idea of assumptions. I typically think of assumptions being, like, so important mostly in debugging rather than analysis. In fact, I wrote a whole blog post about why listing your assumptions is so important as part of your debugging process. Now, like, my mind is spinning a little bit. I'm like, oh, I wonder if I could use some of those, like, debugging techniques as part of more of my analysis step. And could that make me better? So, I think you've put me on a whole, like, thought track of, like, oh, how many of these debugging techniques can I use to make my analysis better? So, that's really cool. STEPHANIE: Yeah, and vice versa. So, a few minutes ago, I'd asked you how you make time for that analysis. Because I was thinking that, you know, in my day-to-day work, I'm juggling so many things. I often find myself running out of time and not able to do all of it. And that, I think, leads us really well into our topic for this episode, which is productivity tricks and ways that we make the most use out of our limited time. JOËL: I think I may have a maybe a bit of a controversial opinion on productivity tricks. I feel like a lot of productivity tricks don't actually make me that much faster. Like, maybe I save a couple of minutes a day, maybe 5 or 10 a day with productivity tricks. And, sure, that adds up over the course of a year. But there are other things I could do in terms of, like, maybe better habits, better managing of my schedule that probably have a much more significant impact. Where I think they are incredibly valuable, though, is not directly making me better with my time management but managing my focus, allowing me to kind of keep in the flow and get things done without getting sidetracked. Or just kind of giving me the things that I need in the moment that I need them so that I'm not getting on to a subtask that I don't really need to be doing. STEPHANIE: Yeah. I really like that reframing of what helps you focus because as I was brainstorming ways that I stay on track for my work, I think I ended up discovering a similar theme where it wasn't so much, like, little snippets and tools for me, as opposed to how I structure all of the noise, I guess, in my day-to-day work and being able to see what it is that I need to care about the most right now. JOËL: I think one of the things that I've tried to do for myself is to make it easy to have access to the information and the tools that I need. Probably one of the most useful bits of that is a combination of the documentation viewer Dash and the...I'm not sure what it would be called– launcher, productivity manager tool for Mac. Alfred, with a CMD + Space, it brings up this bar I can type into. And then you can trigger all sorts of things from there. And so I can type the name of a language or some kind of keyword that I have set up and the name of a method. And then, all of a sudden, it'll show me everything like, you know, top five results. And I can hit Enter, and it will bring up the documentation for that. So, if I want to say, oh yeah, what is the order of the arguments for Enumerable's inject method (which I constantly forget)? You know, it's a few keyboard shortcuts, you know, CMD + Space Ruby Enumerable inject. It's fuzzy finding, so I probably don't even need to type all of that. Hit Enter, and I have the documentation right in front of me. So, that makes it so that I can get access to that with very little amount of context shifting. STEPHANIE: Yeah. I like what you said about how the tools are really helping you, like, narrow down, like, the views of, like, what is most important for you in that moment, and it's doing a little bit of that work for you. I think the couple of tools and apps that I actually did want to share are kind of similar. One MacOS app I really like is called Rectangle for windows management, which is really crucial for me because I don't enjoy like, swiping and tabbing between applications. I would much prefer just seeing, usually, just two things. I try to keep my screen limited to two different windows at once because once it gets more than that, I'm already just, like, overwhelmed [laughs]. And as I'm trying to focus a little bit more on just having, like, one thing be the focus of my attention at a time, Rectangle has been really nice in just really quickly being able to do my windows resizing. So, I usually have, like, either things split between my screen half and half. Like, right now, I have your face on my screen as we record this podcast, and then my notes editing software for taking notes about what we talk about. During my development workflow, it's usually, you know, just my editor, my terminal, and then maybe my browser ends up being, like, the thing that I tab into. But I'm able to just, like, set that all up, and as I need those windows to change depending on what my focus has been shifted to, to kind of make more space for whatever I'm reading, or looking at, or processing visually. The keyboard shortcuts that Rectangle...that I have now, you know, ingrained into my fingers [laughs] has been really helpful. It's like, I'm not fussing with just, like, too many things open. JOËL: I have yet to, like, dive into a window manager. I'm still in the clunky world of CMD tabbing. But maybe I should give that a try. STEPHANIE: For me, it has helped even just, like, identify the things that I need to give more space to on my screen and aggressively, like, cut everything else [laughs]. So, that's a really great MacOS app. And then, the other one is actually kind of a similar vein. It's called Meeter, M-E-E-T-E-R. And it has been really helpful for managing my meetings, especially my video call meetings where the video call software that's being used for the meeting may be variable. And also, when I have multiple email addresses that meetings are being sent to, you're able to sign into all of your calendar accounts. And it provides a really nice view of all of your meetings. It has a really, like, minimal, I guess, design in your toolbar, where it shows you how many minutes until your next meeting. And from that toolbar button, you can click to go to the video conferencing software directly for whatever meeting is up next. And you don't have to, you know, scramble to open Google Meet, or Zoom, or Webex, or whatever it is. And that's [chuckles] been nice, again, just kind of, like, cutting down on the amount of stuff that I need to remember and shift through to get to my destination. JOËL: I think I'm hearing kind of two themes emerge out of some of the things that we've shared. And I'd like to maybe explore them a little bit; one is the power of keyboard shortcuts. And I think that's maybe what a lot of us think of when we think of productivity apps, at least developers, right? We love keyboard shortcuts. And then, secondly, I think I'm hearing automation, right? So, you don't have to go through and, like, find that email or calendar link to find the Zoom link or whatever. It shows up in your toolbar. So, maybe we can dig into a little bit of the idea of keyboard shortcuts. Are you a person who like customizes a lot of keyboard shortcuts? And is that a part of your kind of productivity setup? STEPHANIE: Well, a while ago, we had talked about not keyboard shortcuts in the context of productivity, but I think I had mentioned that I was trying to use my mouse less [chuckles] because I was getting a little bit of wrist pain. And I think that actually has rolled into a little bit of, you know, just, like, more efficient navigation on my computer. I think my keyboard shortcut usage is mostly around window management, like I mentioned. I do feel like I have, like, a medium amount of efficiency in my editor. Sometimes, when I'm pairing with other people who use Vim, I'm, like, shook by how fast they're moving. And I have figured out what works for me in VS Code, and I don't think I need to get any faster. You know, I've just accepted that [laughs]. In fact, it's almost, like, the amount of speed and friction that I have, in my experience, is actually a little more beneficial for the speed that my mind works [laughs]. It kind of helps me slow down when I need to think about what I'm doing as opposed to just, like, being able to, like, do anything at my fingertips, and kind of my brain is just not able to think that fast. And then navigating Slack, which is where I also spend a lot of my time on my computer. Now, using Slack with my keyboard shortcuts has been really helpful because, again, I'm not, like, mindlessly browsing or clicking around. I'm just looking at my unread messages. One non-keyboard shortcut I really like with Slack is Command + K, which is the jump-to feature. And so, I'm using that to go to a specific channel that I know I'm looking for or my own personal DMs, where I keep a lot of notes as well. And, honestly, I think that's, like, the extent of my keyboard shortcut usage. I'm curious what your setup is in regards to that, though. JOËL: I think I'm similar to you in that I have not kind of maxed out the productivity around keyboard shortcuts. You'd mentioned the jump to in Slack. Several pieces of software have something kind of like that. It might be some sort of omnibar, or a command palette, or something like that, where you really just need to know...CMD + K, or CMD + P, CTRL + P are common ones. Then you can sort of, like, type a few characters to just describe the thing you want to do, or a search you want to make, or something like that. Just knowing that one keyboard shortcut for your one piece of software gets you, I don't know, 80% of the productivity that you want. It's kind of amazing. I love the idea of an omnibar. STEPHANIE: Yeah, I hadn't heard of omnibar as a phrase before, but that feels very accurate. I like that a lot, too, where it's, like, oftentimes, I don't do whatever particular thing enough necessarily for it to justify a keyboard shortcut, for me at least. I'm still able to be fast enough to get to, like I said, that final destination or the action that I want to take with a more universal shortcut like that. JOËL: In my editor...so I use Vim, and I got used to Vim's keyboard-based navigation. And that is something that I deeply appreciate, maybe not so much for speed but being able to almost kind of feel one with the machine. And the cursor moves around, and I don't have to, like, think about moving it. It's really a magical sort of feeling. And it's become so much muscle memory now that I can just sort of...the cursor jumps around, things change out. And I'm not, like, constantly thinking about it to the point where now, if I'm in any other editor, I really want to get those shortcuts or, I guess, maybe not shortcuts but a Vim-style navigation, keyboard-based navigation. STEPHANIE: Yeah, it sounds like it's not so much the time savings but the power that you have or the control that you have over your tools. JOËL: Yes. And I think, again, the idea of focus. Navigation has stopped becoming a thing where I have to actively think about it. And I feel like I really do just sort of think my fingers are on the keyboard. I'm not having to, like, do a physical motion where I switch my hands. Like, I'm typing, and I'm writing code, then I have to switch my hand away to a mouse to shift around or, like, move my hand off the home row to, like, find the arrow keys and, like, move around. I just kind of think, and the cursor jumps up. It's great. Maybe I'd be the same if I'd put a lot of time into getting really good at, you know, maybe arrow-based navigation. I still think the mouse you have to move your hand off. It breaks just in the tiniest little way the flow. So, for me, I really appreciate being fully keyboard-based when I'm writing code. STEPHANIE: Right. Being one with the keyboard. As you were talking about that, I very viscerally felt, you know, when you encounter a new piece of technology, and you're trying to navigate it for the first time, and you're like, wow, like, that takes so much mental overhead that it's, you know, just completely disruptive to the goal that you're trying to achieve with the software itself. JOËL: Yeah, it is a steep learning curve. So, we've talked about custom keyboard shortcuts in the editor. But it's common for people to augment their editor with plugins, maybe even some kind of, like, snippet manager to maybe expand snippets or to paste common pieces in. Is that something that you've done in your editor setup? I think you said you use VS Code as your sort of daily editor. STEPHANIE: Yeah, that's right. I actually think I almost forgot about some of my little bits of automation because they are just so spelled for me [laughs] that I don't have to think about them. But you prompting me just now reminded me that there are a few that I'd like to shut out. Snippets-wise, I mostly use them for when I'm writing tests and just having the it blocks or the context blocks expand out for me so I don't have to do any of that typing of the setup there. And since I do use a terminal outside of my editor...I know that some people really like kind of having that integrated and being able to run tests even faster without having to switch to a different application, but I like having them separate. There is a really great plugin called Go to Spec where you can be in any, you know, application code file, and it will pull up the spec file for you. I've been really enjoying that, and that is what helps my test writing be a little more automated, even though I'm having it in separate applications. JOËL: That is really useful. So, as a Vim user, I also have a plugin that does something similar, where I can switch to what's considered the alternate for a particular file, which is typically the spec, or if I'm in the spec, it'll switch to the source file that the spec is testing. STEPHANIE: And then, I do have one really silly one, which is that I got so sick and tired of not remembering how to, you know, type the symbols for string interpolation in Ruby that has also become a snippet where the hash key and the [inaudible 28:48] brackets can [laughs] populate it for me. JOËL: I love it. So, Stephanie, I'd like to go back to something you were talking about earlier in the show. When you were sharing about what was new in your world and, you mentioned that you subscribe to the Substack and that you subscribe to, actually, a lot of newsletters, and you said something that really caught my attention. You were saying that you don't want these all cluttering up your email inbox. And instead, you send all of these to an RSS reader application. What kind of application do you like to use? STEPHANIE: I use Feedbin for this. And I actually think that this was recommended by Chris Toomey back in the day on a previous Bike Shed episode before you and I hosted the show. But that has been really awesome. It has a just, like, randomly generated email address you can use when you sign up for newsletters. You use that instead. And I really like having that distinction because I honestly treat my email inbox as a bit of a to-do list, where I am archiving or deleting a lot of stuff. And then the things that remain in my inbox are things that I need to either respond to, or do, or get back to in some way. And then yeah, when I've completed it, then that's when I archive or delete. But now that we do have all this great content back in email form, I needed a separate space for that, where I similarly kind of treat it as, like, a to-read list. And yeah, like, I look at my unreads in the newsletter RSS reader that I'm using and go through that when I'm in a blog-reading kind of mood. JOËL: I really like that separation because I'm kind of like you. I treat my inbox as a to-do list. And it's hard to have newsletters come in and, like, I'm not ready to read them. But I don't want them in my to-do, or, like, they'll just kind of sit there and get mixed in and maybe, like, filtered down to the bottom. So, having that explicit separation to say, hey, here's the place I go to when I am in a reading mood, then I can read things. I think there's also I've sort of trained myself to only check my email during certain times. So, for example, I will not check my work email outside of working hours. But if I'm on the subway going somewhere and I've got some time where I could do some reading, it would probably be a good thing to be going through some kind of newsletter or something like that. So, I either have to remember to go back to it, or what I tend to do is just scroll Twitter and hope that someone has shared that link, and then I read it there, which is not a particularly effective way of doing things. So, I might try the RSS feed reader tool. What was it called? STEPHANIE: Feedbin. JOËL: Feedbin. All right, I might try to get into that. STEPHANIE: Yeah, I look forward to hearing if that ends up working for you because I agree, having the two separate spaces has been really helpful because I don't want to get distracted by my email/to-do list inbox if I'm just wanting to do a bit of reading, enjoy some content. So, one more theme around productivity that I don't think we've quite mentioned yet, but maybe we've talked a little bit around, is the idea that it's, at least for me, it's a product of time and energy. So, even if you have all the time in the world, you know, you can just stare into space or, like, stare at a line of code and not get [laughs] anything done. JOËL: I know the feeling. STEPHANIE: Right? I am kind of curious how or if you have any techniques for managing that aspect. When your focus is low like, how can you kind of get that back so that you can get back to doing your tasks or getting what you need to do done? JOËL: If I have the time, taking a break is a really powerful thing, particularly taking a break and doing something physical. So, if I can go outside and take a walk around the block, that's really helpful. And if I need a shorter thing that can be done in, like, five minutes or something, I have a pull-up bar set up in my place. So, I'll just go up and do a few sets there and get a little bit of the heart rate slightly up, do a little bit of blood pumping. And that sometimes can help reset a little bit. STEPHANIE: Nice. Yes, I'm all for doing something else [chuckles]. Even when you know that this is a priority or is kind of urgent or whatever, but you just can't get yourself to do it, I've found that asking myself the question, "What would make this task easier for me right now?" has been helpful during those moments. And, for me, that might be grabbing a friend, like, maybe I'm blocked because I'm really just unmotivated. But having someone along can kind of inject some of that energy for me. And then, there's a really great blog post by a woman named Mandy Brown. It's called Energy Makes Time. And she talks about how doing the things that fill our cup, actually, you know, even though it seems like how could we possibly have time to be creative, or, like you said, maybe do something physical, those seem, like, lower on the priority list. But when you kind of get to the point where you just feel so overwhelmed and can't do anything else, and you just go do those things that you know feel good for you, you kind of come back with a renewed perspective on your to-do list. And you can see, like, what things actually aren't that critical and can be taken off. Or you just find that you have the capacity or the energy to get the things that you are really dreading out of the way. So, that has been really helpful when I just am feeling blocked. Instead of, like, feeling bad about how unproductive [chuckles] I'm being, I take that as a sign of an opportunity to do something else that might set me up for success later. JOËL: Yeah. I think oftentimes, it's easy to think of productivity in terms of, like, how can I maybe eliminate some tasks that are not high value through clever automation, or keyboard shortcuts, or things like that? But oftentimes, it can be more about just sort of managing your focus, managing your energy. And by doing that, you might have a much higher impact on both how productive you feel—because that's an important thing as well, in terms of motivation—and, you know, how productive you actually are at getting things done. STEPHANIE: Right. At least for me, like, not all TDM is bad and needs to be automated away, but, like, my ability to, like, handle it in the moment. Whereas yeah, sometimes maybe I've just run the same few lines that should be just a script [chuckles], that should just be, you know, one command, enough times that I'm like, oh, like, I can't even do this anymore because of just, like, other things going on. But other times, like, it's really not a big deal for me to just, you know, run a few extra commands. And, like, that is perfectly fine. JOËL: I love writing a good Vim macro. Yeah. So, it's important to think beyond just the fun tools and the code that we can write. Kind of think a little bit more at that energy and that mental level. That said, there are a ton of great tools out there. We've named-dropped a bunch of them in this episode. For our listeners who are wondering or who weren't, like, necessarily taking notes, we've linked all of them in the show notes: bikeshed.fm. You can find them there. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Stephanie has another debugging mystery to share. Earlier this year, Joël mentioned that he was experimenting with a bookmark manager to keep track of helpful and interesting articles. He's happy to report that it's working very well for him! Together, they discuss tactics to ensure the easiest route also upholds app health and aids fellow developers. They explore streamlining test fixes over mere re-runs and how to motivate desired actions across teams and individuals. Raindrop.io (https://raindrop.io/) Railway Oriented Programming (https://fsharpforfunandprofit.com/rop/) 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 have another debugging mystery to share with the group. I was working on a bug fix and was trying to figure out what went wrong with some plain text that we're rendering from a controller with ERB. And I was looking at the ERB file, and I was like, great, like, I see the method in question that I need to go, you know, figure out why it's not returning what we think it's supposed to return. I went down to go check out that method. I read through it ran the tests. Things were looking all fine and dandy, but I did know that the bug was specific to a particular, I guess, type of the class that the method was being called on, where this type was configured via a column in the database. You know, if it was set to true or not, then that signaled that this was a special thing. You know, I made sure that the test case for that specific type of object was returning what we thought it was supposed to. But strangely, the output in the plain text was different from what our method was returning. And I was really confused for a while because I thought, surely, it must be the method that is the problem here [laughs]. But it turns out, in our controller, we were actually doing a side effect on that particular type of object if it were the case. So, after it was set to an instance variable, we called another method that essentially overwrote all of its associations and really changed the way that you would interact with that method, right? And that was the source of the bug is that we were expecting the associations to return what we, you know, thought it would, but this side effect was very subvertly changing that behavior. JOËL: Would it be fair to call this a classic mutation bug? STEPHANIE: Yeah. I didn't know there was a way to describe that, but that sounds exactly right. It was a classic mutation bug. And I think the assumption that I was making was that the controller code was, hopefully, just pretty straightforward, right? I was thinking, oh, it's just rendering plain text, so not [laughs] much stuff could really be happening in there, and that it must be the method in question that was causing the issues. But, you know, once I had to revisit that assumption and took a look at the controller code, I was like, oh, that is clearly incorrect. And from there, I was able to spot some, you know, suspicious-looking lines that led me to that line that did the mutation and, ultimately, the answer to our mystery. JOËL: Was the mutation happening directly in the controller? Or was this a situation where you're passing this object to a method somewhere, and that method, you know, in another object or some other file is doing the mutation on the record that you passed in? STEPHANIE: Yeah, that's a great question. I think that could have been a very likely situation. But, in this particular case, it was a little more obvious just in the controller code, which was nice, right? Because then I didn't have to go digging into all of these other functions that may or may not be the ones that is doing the mutation. But the thing that was really interesting is that it seems like that method that does this mutating is pretty key to the type of object that we're working with, as in most places it's used, that mutation happens. And yet, it's kind of separated from the construction of that object. And I was, I think, a little bit surprised that it wasn't super obvious that throughout the application, this is the way that we treat this special object. And I had wished that maybe that was a bit more cohesive or that it was kind of clear that this is how we use this in our domain. And it was, like, lacking that bit of clarity around how things are used in practice as opposed to trying to keep those in isolation. JOËL: Yeah. Because now you have sort of two different diverging use cases for using this object that are incompatible, one that's trying to use the object as is and the other that's depending on this mutation. Now you can't have both. STEPHANIE: Right. As far as I can tell, in most cases, you know, we're using it with a mutation, and maybe there is a good reason for those ideas to be separate. But it certainly did not make my life easier trying to solve this particular bug. JOËL: I'm hearing you mention the idea of ideas being separate; definitely kind of triggers some pathways in my modeling brain, where I'm already thinking, oh, maybe this should be a decorator, or maybe this is just a straight-up transformation. We just have a completely different kind of object rather than mutating the underlying record. STEPHANIE: Yeah, definitely. I think there could have been some alternative paths taken. At the time, that was kind of decided as the way forward for how to treat this particular domain object. So, that's my fun, little mystery where I got to, you know, play the detective role for a bit. Joël, what's new in your world? JOËL: So, earlier this year, on an episode of The Bike Shed, I mentioned that I was experimenting with a bookmark manager to kind of keep track of articles that I find are helpful that I might want to reference later on. I wasn't sure if it was going to be worthwhile and mentioned that I'd report back. I'm happy to report that it is working very well for me. So, the tool is Raindrop.io. They have an app. They have a website. And I have been sort of slowly filling it with some of my most commonly referenced articles. I had pulled some in initially, and then kind of over time, when I find myself referencing an article using my old-fashioned approach, which was just remember the keywords in the title and Google them, now I'll do that, link the article to someone else, and then add it to Raindrop so that the next time I'm starting to look for things, I have these resources available. And I try to curate a little bit by doing things like tagging them and categorizing them so that when I need references for something, I don't just have to go through my personal memory and be like, oh yeah, what articles do I have on data modeling that I think might be a good fit here? Instead, I can just go to the data modeling section of Raindrop and be like, oh yeah, these five are, like, my favorites that I link to all the time. STEPHANIE: Wow. We did a whole episode on how to search recently. And we totally forgot to mention things like bookmark managers or curating your own little catalog of go-to articles. In some ways, now you have to search within your bookmark manager [laughs]. JOËL: That's true. Sometimes, it's searching if I'm looking for a particular article, and sometimes, it's more browsing where I'm looking at a category, or a tag, or something like that, which maybe would have been another interesting distinction to explore on the How to Search episode. I do want to give a shout-out to the most recent article that I looked up in my bookmark manager here, Railway-Oriented Programming. It's an article on how to deal with pieces of code that can error and how to sort of compose those sorts of methods. So, you now have a whole sort of chain of different functions that can error or not in different sorts of ways. And it uses this really powerful metaphor of railway with different types of junctions and how you might try to, like, fit them all together so that everything connects nicely. And it's just a really beautiful metaphor. And I was doing some work on error handling, in particular, and I wanted to reference something and that was a great resource for that piece of work. STEPHANIE: Very cool. I'm really intrigued. I love a good metaphor. I am curious: is this programming language and framework agnostic and not about Rails? JOËL: Actually, so this is written on an F# blog. So, the code is all in F#. And it leans a little bit into some functional programming concepts, but the metaphor is more generic. So, it's a really fun way to think about when you're programming, and you're not just going through the happy path. But what are all the side branches that you might have to deal with, and how do those side branches come back into the flow of your program? STEPHANIE: Very cool. I can also see some really excellent visuals here if you were to use this metaphor as a way of understanding complexity. JOËL: Absolutely. In fact, this article has some pretty amazing visuals, so strong recommend. We'll link it in the show notes. STEPHANIE: So, a few episodes ago, we talked about code ownership at scale because my client project that I'm working on is for a company with hundreds of developers. So, it's quite a big codebase, quite a big team. One of the main issues that I, at least, struggle with on a day to day is flaky tests in CI. When I, you know, I'm wanting to merge a change, I often have to run the test suite a few times to get to green and be able to merge and deploy. And this is an interesting topic to me because when you're really trying to just get your changes through and mark that ticket as done, it's very tempting to just hit that, you know, retry button and let it sit and just hope for the best, as opposed to maybe investigate a little further about why that test was flaking and see if there's something that you could do about it. So, I wanted to talk to you about the idea of making the right thing easy or how, at both a team level and an individual level, we can set ourselves and our team up for success rather than shoulder this burden [laughs] and just assume that things are the way they are. JOËL: That's a really powerful question. Because I think by default, oftentimes, the less helpful thing is the path of least resistance, so, in this case, hitting that rerun button on a test suite, which I've absolutely done. But there's a lot of other situations in our work where, just sort of by default, the path of least resistance is the thing that's maybe less helpful for the team. STEPHANIE: Ooh, I noticed that you kind of reframed what I said. I was using the term, you know, the right thing, but you then reworded it into the helpful thing. And that actually gets me thinking about these words are kind of subjective, right? What is helpful to someone could be different to what's helpful to someone else. And I'm kind of curious about your definition of the helpful thing. JOËL: Yeah, I mean, sometimes it's very easy to sort of bring absolutes and [inaudible 11:26] judgments to code, you know, when we talk about writing good code, and being good programmers, being good at our jobs, not doing the bad things. And I think that sort of absolutism sometimes can, like, be very restrictive, and kind of takes us down paths that are not optimal for ourselves, for our teams, for our products. So, I'd like to think a little bit more relativistically have a little bit more of elasticity in the way that we formulate some of these ideas. STEPHANIE: Yeah. I really like that reframing, and I appreciate the nuance there. I think for me, when I think of doing the helpful thing, I'm hoping to ease the day-to-day workflow for other developers because that also includes myself, right? Like, I've certainly been there feeling frustrated or just kind of tired of retrying [laughs] the test suite over and over again. I'm also thinking about helpful, as in what will be helpful for future developers regarding the product? And can we make it robust now so that we're not dealing with bug reports later for things that we maybe we're trying to throw under the rug or just kind of glance over? Do you have any other guiding principles around what is helpful and what's not? JOËL: I think that the time horizon you mentioned is really interesting because you have to balance sometimes short-term value versus kind of long-term. And is it worth it to maybe not fix that flaky test today so that we can ship as soon as possible? Or is it worth investing a little bit of time today so that tomorrow or next week is better? If you're a solo developer on a tiny project, that might be of personal benefit only. But on a larger team, you know, that might benefit not just you but a larger amount of people. STEPHANIE: I just imagined the trolley problem [laughs] a little bit about, you know, the future developers and whose lives, not lives but whose happiness, the developer happiness you'll save [laughs] when you're on that track and making the decision about benefit now versus benefit later. JOËL: No connection to railway-oriented programming, by the way. STEPHANIE: I am really interested in also talking about barriers to doing the helpful thing or taking that extra step, right? Because I think identifying those barriers is really important to then, hopefully, break them down so that we are creating that path of least resistance. JOËL: That's interesting that you mentioned these as barriers because I think, in my mind, I was thinking about the same idea but from, like, a completely mirror perspective, the idea of incentives. Why do incentives push you in one way versus the other? STEPHANIE: I like that a lot. I think maybe there are, like, two different levers, right? Or maybe they are two sides of the same coin, where you do have incentive, and then you also have things that disincentivize you. JOËL: This reminds me a little bit of the idea of the tragedy of the commons. So, in the case of flaky tests, everybody as a whole on your project has a worse experience. And project velocity slows when there are flaky tests. But you, as an individual developer, are incentivized to ship features quickly and efficiently. And the fastest way you can get your individual feature to production is by hitting that rerun button. Even though, collectively as a whole, every time we do that, instead of fixing the flakiness, we're adding a tiny, little bit of extra slowness that will accrete over time. STEPHANIE: Yeah. It's kind of difficult to imagine really the negative impact that it's having collectively, right? You're kind of like, oh, I'm feeling this pain, but you're not always, like, really hearing about it from others, and we might just be silently suffering together [laughs]. I do think that once it's been identified as like, oh, like, we're all actually, like, really impacted by this, okay, great, let's make it a priority. And so, now, let's say I am slightly incentivized to go and investigate the flakiness of a test rather than hit the rerun button this time around. I am wanting to talk about those barriers I was referring to a little bit because I've been in this position where I'm like, okay, like, I have some extra time today. So, why don't I look into this? But then I go down that path, and now I'm looking at a test written by someone many years ago, you know, I don't know this person, and I don't know this domain. I don't know who to talk to to figure out even where to start. I may or may not feel equipped with the right tools to be able to address it. And then, I think the biggest challenge is not feeling like it matters, right? Once I'm hitting this barrier, I'm like, is it worth the effort? At that point, maybe a little bit demoralized because, well, this is just one, and we have so many other flaky tests, like, what's one more? JOËL: That's really interesting that you mentioned that sort of morale factor because it's absolutely the case on every flaky test suite I've seen. I think that kind of points to almost, like, an exponential cost to ignoring the problem. If someone fixed it early, yeah, it's slightly annoying, but you get it done. You fix it, and then you move on. When it feels like there's now this insurmountable pile of these and that any work you do here doesn't bring you any closer to the goal because it's effectively infinite, yeah, now, there is no incentive at all to do that work. STEPHANIE: So, to avoid that, we talked about incentives, right? And I'm kind of curious: what ways have you seen or experienced that did make you feel motivated to take that extra step or at least try to avoid that point of thinking that nothing matters? [laughs] JOËL: So, I'm going to start with, I think, what's maybe a classic developer answer, and I'm curious to get your thoughts on it because I think I have very mixed feelings about this. The idea of programmer discipline—we just need to kind of take more pride in our craft and pursue excellence, choose to do the right thing, even when it's hard every day. Because I hear a lot of that in our communities. How do you feel about that sort of maybe a bit of a mindset change? And how effective has that been? STEPHANIE: Whoa, yeah, that's a really great point because I think I also feel quite conflicted about it. Because sometimes I can find it in myself to be, like, you know, I have the energy today to want to uphold, like, a certain level of quality that would make me feel good about doing my best work. And then, there are other days where I am, you know, just tired, [laughs] or feeling a little bit lazy, feeling just not confident that it will be worth it. Because there's also, I think, some external forces, right? I've certainly been in the position where we were only rewarded or celebrated for shipping fast. That was the praise we were getting at retros. But then that actually really disincentivized me from wanting to do the helpful thing when the time came, right? When I'm in my development process, and I'm at, like, that crossroads. Because I'm like, well, I've been trying to do the right thing, but, like, no one is celebrating me for it. What if it takes away time from doing the thing that is considered successful? And, like, does it have an impact on me and my job? So, you can, you know, kind of go down that spiral pretty quickly. And, in that case, like, no amount of personal, like, individual [laughs] feelings of responsibility can really overcome those consequences if, like, you're working on a team where that is just simply not valued, and there are other people who have authority to impart consequences, I suppose. JOËL: Yeah. It's, you know, you have that maybe some amount of personal motivation. You feel like you're swimming upstream. And so, maybe the question then is, how do we reorient maybe some of the incentive structures in a team to try to make it so that if you are, let's just say, chasing some of those extrinsic rewards and you're trying to get praise from your teammates, or move forward in your career, whatever it is that is rewarded and valued on your team, how can that be harnessed to push people in a direction to get some of these extra tasks done? STEPHANIE: Yeah. I will say, though, it is a little bit of both. And I think that was maybe why we're both kind of conflicted about it. Because on the individual level and, in general, knowing what my values are and, like, wanting to do good work and uphold quality, there are times where I don't always behave according to those values. Like I said, I am feeling tired, or maybe it's, like, almost 5:00 o'clock, and I just want to, you know, push my thing [laughs] so I can go and go on with my day. What has helped me is having an accountability buddy. Maybe it's in code review, or maybe it's when I'm pairing, or maybe just talking about a problem that we're facing, right? And I might get into that sort of lizard-brain mentality of just wanting to do the easy thing. But as soon as someone else points it out or is, like, you know, like, "That's not quite aligning with what I know your, like, hopes and goals are for this project or how you want to do your work," usually, that's enough to be like, "Yeah, you're right." [laughs] And I'll take another pass at it. JOËL: And I think we've kind of come back full circle here in that you mentioned that sort of the lizard brain side of you wants to just do the easy thing with the implication that, in this case, the easy thing is the thing that's maybe not useful to the team long term. What if we could restructure things a little bit so that the easy thing was the most beneficial thing for the team? And now you're not having to use discipline to fight the lizard brain side of you, but you're actually working with it. One thing I've seen teams do with flaky tests is to not necessarily fix them immediately. Like, maybe you do rerun them, but when they happen, create a ticket for them and put them into the planning board. And so, now, these are things that get prioritized. They're things that might be fairly quick to do. So, it might be a fun, like, fast ticket for someone to pick up at the end of the week. It now counts towards velocity if tracked, so people, hopefully, get rewarded for doing that work. Is that something that you've seen? And how effective do you think that is in maybe making fixing flaky tests easier thing for a team? STEPHANIE: Yeah, that is actually something that we are doing on my team right now, and I think it's great. I like the idea of tracking it, right? Because then you could also see over time, like, whether we have been getting better at reducing flaky tests, you know, then it's also really clear when someone is preoccupied with that work, and they don't get assigned something else. One way that I've seen it not work as well as we hoped is when other work consistently gets prioritized over those flaky test tickets, and, you know, sometimes it happens. I think that's also information, though, about the team and how the team is spending its time compared to how the team thinks it should be ideally spending its time where, you know, we can say all we want, like, yes, like, we really want to make sure our test suite is robust. But when other things are consistently getting prioritized over it, then you can point to it and say, do we actually believe this if we're consistently not behaving according to that belief? I found that challenging to have that conversation. But I do think that the concreteness of adding it to our workload for a given period of time is at least providing information rather than it being things that, like, developers are doing one-off or kind of just on their own time. JOËL: Another solution that I've seen people do, and this is a classic developer solution, is tooling. If you have better tooling around a particular problem, sometimes you can shift that cost, that time of work it takes so that it's easier to do the best thing rather than to not...or at least make it easy enough that it's less of a big decision, like, oh, do I really want to invest that much work into something? And a classic example of this, I think, is when you're trying to get into more of a test-driven development workflow. Having a test suite that's fast and, really importantly, having a near-instant way to run a test from your code editor makes a big difference in terms of adopting that workflow. Because if the cost of running a test is too high, then yeah, the easy path is to just say, you know what? I'm not going to run a test. I'm going to just run it once at the end after I've written 100 lines of code or an entire feature. And now I am not getting the benefits of TDD. And that might kind of get into a negative cycle where because I'm not seeing the benefits, I do it even less. And then eventually, I'm just, like, you know what? Forget this whole thing. STEPHANIE: I think that also applies to testing in general, where if it, you know, is feeling really challenging. I have definitely seen people start to get into that mindset of, is this worth my time to do at all? And it's a very slippery slope, I think. That almost makes me think about, like, okay, like, what are some other ways to lift that task up and to elevate it into something that's worthy of saying, like, "Hey, like, that was really hard, and you did a great job. And that was really awesome that you persevered through that challenging thing." Sharing the pain points is really important, not only to, like I mentioned earlier, to, like, communicate that, oh, maybe, like, more people than you think are going through the same thing, but also to be able to identify when someone went out of their way to do the helpful thing and seeing that someone was willing to do it because, for them, being helpful is important. When I see someone on my team take on kind of a difficult task to make things easier for others and then share about it, I feel really inspired because I think, wow, like, that could be me as well. You know, there's that saying that many hands make light work. And I also think that's true of tackling these kinds of barriers, where if we all feel this collective responsibility or, like, wanting to help out the group, it ends up literally being easier. JOËL: I think something I'm hearing here as well is the value of giving praise. If somebody goes out of their way to make life easier for the rest of your team, give them a shout-out, whether that's in your team's Slack channel, maybe it's at an all-hands meeting, and you shout out some work that they've done or, you know, you put their name on a slide in your slide deck at some point, or whatever it is the mechanism within your team. Having a way to shout out people who've done some of this work that can be sometimes a little bit thankless is a great way to motivate seeing more of that. STEPHANIE: Yeah. I was just thinking that it can be really powerful because, like you said, a lot of it is thankless, but also, we may not even realize the impact it's having on others until you give that shout-out and express, like, "Wow, like, that change, you know, I've been bothered by this issue for so long and, you know, that really made an impact on me," just keeping that cycle of gratitude going. JOËL: So, I think we've kind of identified three maybe main areas of ways where you can help to incentivize these behaviors. You can do it through kind of process. We talked about the example of pulling the flaky tests as actual cards to be worked through on a board. It can be technical by introducing some tooling that makes it much easier to do the work that you're trying to do. And it can be personal by praising people, preferably in public, for taking that extra step. And I think all three of those can be part of a strategy to make it easier or more attractive for people to do work that benefits the team as a whole, even if they don't see an immediate return to that on a per-day level. STEPHANIE: Yeah. I like that we kind of talked about these three different categories. And people in all different types of roles can, hopefully, take something from what we've shared, right? If you are a manager or leader of a team, maybe you can investigate your processes. If you're an individual contributor and you notice your colleague doing something that you, you know, kept meaning to but just didn't have time for, recognize that work. It really does take a holistic approach, but I think an impact can be made at every level. JOËL: Agreed. I think for managers and more senior team members, that's really almost, like, part of their job description is to think about these kinds of things. How can we incentivize this work? How can we shift the team in a particular direction? There's a particular onus on them to do this right, to think about this, to model some of this behavior. STEPHANIE: Yeah, absolutely. JOËL: For someone who's really senior on a team also, they're often the ones who are tasked or who maybe take the initiative to build some of this more complex tooling so that these tasks are easier for more junior people. Maybe that's tinkering with some things and building an editor plugin that makes it easier to do some work. Maybe it's building a Rails generator so that the proper files get generated that maybe people wouldn't think to have when they're building certain work. Maybe it's building an RSpec matcher to make it easier for people to test some of the nuances of what we're hoping to do, catching some of these edge cases. Whatever it is, sometimes there are things that the more junior members of our teams aren't aware of, and having a senior person take time out of their day to build these things so that now the entire team can be more productive can be a really helpful thing to do. STEPHANIE: Yeah, that's a great point. And I think that also comes from having a pulse on what people are struggling with, right? So, you know, oh, it would be good to invest my energy into building a script to make this manual process easier because I keep hearing about people having issues with it or it being a challenge. So, I would even recommend posing the question of, like, how do people feel about being able to fix that flaky test, right? Like, is it intimidating? What are those barriers? Because your team knows best about what that experience is like. And if that is not something on your radar, maybe there are opportunities to incorporate it into where you're evaluating team morale and happiness. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Joël shares he has been getting more into long-form reading. Stephanie talks about the challenges she faced in a new project that required integrating with another company's system. Together, they delve into the importance of search techniques for developers, covering various approaches to finding information online. Domain Modeling Made Functional (https://pragprog.com/titles/swdddf/domain-modeling-made-functional/) Episode on heuristics (https://www.bikeshed.fm/398) Episode on specialized vocabulary (https://www.bikeshed.fm/356) Episode on discrete math (https://www.bikeshed.fm/374) Joël's discrete math talk at RailsConf (https://www.youtube.com/watch?v=wzYYT40T8G8) Dash (https://kapeli.com/dash) Alfred (https://www.alfredapp.com/) Indiana Jones and the Crypt of Cryptic Error Messages (https://thoughtbot.com/blog/indiana-jones-and-the-crypt-of-cryptic-error-messages) Browser History confessional by Kevin Murphy (https://www.youtube.com/watch?v=R7LkHjJdH9o) 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: Something I've been trying to do recently is get more into long-form reading. I read quite a bit of technical content, but most of it are short articles, blog posts, that kind of thing. And I've not read, like, an actual software-related book in a few years, or at least not completed a software-related book. I've started a few chapters in a few. So, something I've been trying to do recently is set aside some time. It's on my calendar. Every week, I've got an hour sit down, read a long-form book, and take notes. STEPHANIE: That's really cool. I actually really enjoy reading technical stuff in a long-form format. In fact, I was similarly kind of trying to do it, you know, once a week, spend a little bit of time in the mornings. And what was really nice about that is, especially if I had, like, a physical copy of the book, I could close my computer and just be completely focused on the content itself. I also love blog posts and articles. We are always talking on the show about, you know, stuff we've read on the internet. But I think there's something very comprehensive, and you can dig really deep and get a very deeper understanding of a topic through a book that kind of has that continuity. JOËL: Right. You can build up a larger idea have more depth. A larger idea can also cover more breadth. A good blog post, typically, is very focused on a single thing, the kind of thing that would really probably only be a single chapter in a book. STEPHANIE: Has your note-taking system differed when you're applying it to something longer than just an article? JOËL: So, what I try to do when I'm reading is I have just one giant note for the whole book. And I'm not trying to capture elements or, like, summarize a chapter necessarily. Instead, I'm trying to capture connections that I make. So, if there's a concept or an argument that reminds me of something perhaps similar in a different domain or a similar argument that I saw made by someone else in a different place, I'll capture notes on that. Or maybe it reminds me of a diagram that I drew the other day or of some work I did on a client six months ago. And so, it's capturing all those connections is what I'm trying to do in my notes. And then, later on, I can kind of go back and synthesize those and say, okay, is there anything interesting here that I might want to pull out as an actual kind of idea note in my larger note-taking system? STEPHANIE: Cool, yeah. I also do a similar thing where I have one big note for the whole book. And when I was doing this, I was even trying to summarize each chapter if I could or at least like jot down some takeaways or some insights or lines that I like felt were really compelling to me. And, like, something I would want to, in some ways, like, have created some, like, marker for me to remember, oh, I really liked something in this chapter. And then, from there, if I didn't capture the whole idea in my note, I knew where I could go to revisit the content. JOËL: And did you find that was helpful for you when you came back to the book? STEPHANIE: Yeah, it did. I usually can recall how, like, I felt reading something. You know, if something was really inspiring to me or really relatable, I can recall that, like, I had that experience or emotion. And it's just, like, trying to find where that was and that this is a system that has worked well for me. Though, I will say that summarizing each chapter did kind of remind me of, like, how we learned how to take notes in school. [laughs] And I think, you know, middle school, or whatever, I recall a particular note-taking format, where you, you know, split the page up into, like, an outline with all the chapters, and you tried to summarize it. And so, it did feel a little bit like homework [laughs]. But I can also see the value in why they taught me how to do that. JOËL: I was recently having a conversation with someone else about the idea of almost, like, assigning yourself the college-style essay question after finishing a book to try to synthesize what you learned. STEPHANIE: Whoa, that's really cool. I can see how that would really, like, push you to synthesize and process what you might have just consumed. And, also, I'm so glad I'm not in school anymore [laughs] so that I don't have to do that on a regular basis. [laughs] I'm curious, Joël, what book are you reading right now? JOËL: I've been reading Domain Modeling Made Functional, which is a really interesting intersection between functional programming, Domain-Driven Design (DDD), and a lot of interesting kind of type theory. And so, that sort of intersection of those three Venn diagrams leads to this really fascinating book that I've been going through. And I think it connects with a lot of other things that I've been thinking about. So, I'll be reading and be like, oh, this reminds me of this concept that we have in test-driven development. Or this reminds me of this idea that we do when we do a product design sprint. And this reminds me of this principle from object-oriented design. And now I'm starting to make all these really interesting connections. STEPHANIE: Awesome. Well, I hope to hear more about what you've learned or kind of what you're thinking about going through this book in future episodes. JOËL: This is not the last time we hear about this book, I'm pretty sure. So, Stephanie, what's new in your world? STEPHANIE: So, I have a little bit of a work update to share. So, lately, I've been brought in to work on a feature that is integrating with another company's system. And the way that I was brought into this work was honestly just being assigned a task. And I was picking up this work, and I was kind of going through the requirements that had been specked out for me, and I was trying to get started. And then, I realized that I actually had a lot of questions. It just wasn't quite fully fleshed out for the level of detail that I needed for implementing. And for the past couple of weeks, we've been chatting in Slack back and forth as I tried to get some of my questions answered. They are trying to help me, but also the things that I'm saying end up confusing them as well. And then, I end up having to try and figure out what they're looking for in order to properly respond to them. And I had not met these people before. These are folks from that other company. And, you know, I'd only just seen their little Slack profile pictures. So, I didn't know who they were. I didn't know what role they had and kind of, like, what perspective they were coming to these conversations from. And after a while, I was feeling a little stressed out because we just kept having this back and forth, and not a lot of answers were coming to fruition. And I really ended up needing the nudge of the manager on my client team to set up a meeting for us to all just talk synchronously. And I think I had...not that I had been avoiding it necessarily, but I guess I was under the impression that we were at the point where we could just, you know, shoot off a question in Slack and that there would be a clear path forward. But the more we kept pulling on that thread, the more I realized that, oh, like, we have a lot of ambiguity here. And it really helped to meet them finally, not in person but, like, over a video call. [laughs] So, this happened yesterday. And, you know, even just, like, going around doing introductions, like, sharing what their role was at the company helped me just understand, like, who I was talking to. You know, I realized, oh, like, the level of technical details that I had been providing was maybe too much for this group. And I was able to have a better understanding of what their needs were, like hearing kind of the problem that they had on their end. And I realized that, oh, like, they actually aren't going to provide me the details for implementation that I was looking for. That's up to me. But at least now I know what their higher-level needs are so that I can make the most informed decisions that I can. JOËL: Fascinating. So, you thought that this was going to be, like, the technical team you're going to work with. And it turns out that this was not who they were. STEPHANIE: In some ways. I think I thought by providing more technical details that would be helpful, but it ended up being more confusing for them. And I think I was similarly kind of frustrated because the ways that I was asking questions or communicating also wasn't getting me the answers that I needed as well. But I felt really great after the meeting because I'm like, wow, you know, it doesn't have to be as stressful. You know, when you start getting into that back and forth on Slack, at least I find it a bit stressful. And it turns out that the antidote to that was just getting together and getting to know each other and hashing out the ambiguity, which does seem to work better in a more synchronous format. JOËL: Do you have kind of a preference for synchronous versus asynchronous when it comes to communication? STEPHANIE: That's a good question. I think it's kind of a pendulum for me. I'm in my asynchronous communication is a bit better for me right now phase, but only because I am just so burnt out on meetings a lot of the time that I'm like, oh, like, I really don't want to add another meeting to my calendar, especially because...I amend my statement; I'm burned out of meetings that don't go well. [laughs] And this meeting, in particular, was different because, you know, I realized, like, oh, like, we are not on the same page, and so how can we get there? And kind of making sure that we were focused on that as an agenda. And I found that ultimately worked out better than the async situation that I was describing, which I'm thinking now, you know when things aren't clear, text-based communication certainly does not help with that. JOËL: So, meetings, sometimes they're actually good. STEPHANIE: Yeah, that's my enlightened discovery this week. JOËL: So, this episode is kind of a special one. We've just hit 400 episodes of The Bike Shed. So, this is episode number 400. It's also my 50th Episode as a co-host. STEPHANIE: Right. That's a huge deal. 400 is a really big number. I don't know if I've ever done 400 of anything before [laughs]. JOËL: The Bike Shed has been going on for almost ten years now. The first episode up on the website is from October 31st, 2014, so just about nine years from that first episode. STEPHANIE: Wow. And it's still going strong. That's really awesome. I think it's really special to be a part of something that has been going on for this long. And, I don't know, maybe there are still listeners today from back in 2014. I would be really excited to hear if anyone out there has been listening to The Bike Shed throughout its whole lifespan. That's really cool. JOËL: Looking back over the last 50-ish episodes you and I have done, do you have a favorite episode that we've recorded? STEPHANIE: This may be a bit of recency bias. But the episode that we did about Software Heuristics I really enjoyed. Because I think we got to bring to the table some of the things we believe and the way we like to do things and kind of compare and contrast that with each other. And I always find people's processes very fascinating. Like, I want to know how you think and where your brain is at when you approach a problem. So, I really enjoyed that topic. What about you? Do you have any highlight episodes? JOËL: I think there's probably two for me. One is the episode that you and I did on Specialized Vocabulary. I think this really touched on a lot of really interesting aspects of writing software that's going to scale, software that works for a team, and also kind of personal growth and exploration. The second one that I think was really fun was the episode I did with Sara Jackson as a guest talking about Discrete Math because that's an episode that I got really excited about the topic. And right after recording the episode, it was the last day of the call for proposals for RailsConf. And I just took that raw excitement, put together a proposal, hit submit before the deadline. And it got accepted and got turned into a talk that I got to give on stage. So, that was, like, just a really fun journey from exciting episode with Sara and then, like, randomly turned into a conference talk. STEPHANIE: That's awesome. That makes me feel so happy. Because it just reminds me about how the stuff we talk about on the show can really resonate with people, you know, enough to become a conference talk that people want to attend. And I also really like that a lot of the topics we've gotten into in the past 50 episodes when we've taken over the show have been a bit more evergreen and just about, you know, the software development experience and a little bit less tied to specific news within the community. Speaking of evergreen topics, today, I wanted to discuss with you an evergreen software skill, and that is searching or Search-Driven Development, even if you will. JOËL: Gotta always get that three-letter acronym, something DD. STEPHANIE: Yeah. I am really curious about how we're going to approach this topic because a lot of folks might joke that a big part of writing software is knowing what to Google. Do you agree with that statement or not? JOËL: Yes and no. There's definitely value in knowing what to Google. It really depends on the kind of work that you're doing. I find that I don't Google that much these days. There are other tools that I use when I'm particularly, like, searching through documentation, but they tend to be less sort of open-ended questions and more where it's like, oh, let's get the actual documentation for this particular class or this particular method from the standard library. STEPHANIE: Oh, interesting. I like that you pointed out that there are different scopes of things you might want to search for. So, am I hearing correctly that when you have something specific in mind that you are just trying to recall or wanting to look up, you know, you're still using search that way, but less so if you are trying to figure out how to approach solving a problem? JOËL: So, oftentimes, if I'm working with a language that I already have familiarity with or a framework that I have familiarity with, I'm going to lean on something more specific. So, I'm going to say, okay, well, I don't exactly remember, like, the argument order for Enumerable's inject method. Is it memo then item, or item then memo? So, I'll just look it up. But I know that the inject method exists. I know what it does. I just don't remember the exact specifics of how to do that. Or maybe I want to write a file to disk, and I don't remember the exact method or syntax to do that. There are some ways that you can do it using a bunch of instance methods. But I think there's also a class method that allows you to kind of do it all at once. So, maybe I just want to look up the documentation for the file class in Ruby and read through that a little bit. That's the kind of thing where I suppose I could also Google, you know, how to save file Ruby, something like that. But for those sorts of things where I already roughly know what I want to do, I find it's often easier just to go directly to the docs. STEPHANIE: Yeah, yeah, that's a great tip. And I actually have a little shortcut to share. I started using DuckDuckGo as my search engine in the past year or so. And there's this really cool feature called Bangs for directly searching on specific sites. From my search bar, I can do, let's say, bang Rails and then my query. And it will search directly the Rails Guides website for me instead of, you know, just showing the normal other results that might come up in my regular search engine. And the same goes for bang Ruby doc. That one shows ruby-doc.org, which is my preferred [laughs] Ruby documentation website. I've really been enjoying it because, you know, it just takes that extra step out of having to either navigate to the site itself first or starting more broadly with my search engine and then just scrolling to find the site that I'm looking for. JOËL: Yeah. I think having some kind of dedicated flow helps a lot. I have a system that I use on my machine. It is Mac-specific. But I use a combination of the application Dash and the application Alfred. It allows me, with just a few keyboard shortcuts, to type out language names. So, I might say, you know, Ruby inject, and then it'll show me all the classes that have that method defined on it, hit Enter, and it pops up the documentation. It's downloaded on my machine, so it works offline. And it's just, you know, a few key presses. And that works really nicely for me. STEPHANIE: Oh, offline search. That's really nice. Because then if you're coding on a plane or something, then [laughs] you don't have to be blocked because you can't look up that little, small piece of information you need to move forward. That's very cool. JOËL: That is really cool. I don't know how often I've really leaned into the offline part of it. I don't know about you; I feel like I don't code on airplanes as much as I thought I would. STEPHANIE: That's fair. I also don't code on airplanes, but the idea that I could is very compelling to me. [laughs] JOËL: Absolutely. So, that's the kind of searches that I tend to do when I'm working in a language that I already know, kind of a day-to-day language that I'm using, or a framework that I'm already pretty familiar with. And this is just looking at all the things I haven't gotten to the point where I've fully memorized, but I have a good understanding of. What about situations where maybe you're a little bit less familiar with? So maybe it's a new framework, or even, like, a situation where you're not really sure how to proceed. How do you search when there's more uncertainty? STEPHANIE: Yeah, that's a good question. I do think I start a bit naively. The reason that we're able to be more specific and know exactly where to go is because we've built up this experience over time of scrolling through search results and clicking, you know, maybe all of them on the first page, even, and looking at them and being like, oh, like, this is not what I want. And then, seeing something else, it's like, oh, this is more helpful and kind of arrived at sources that we trust. And so, if it's something new, I don't really mind just going for a basic search, right? And starting more broadly might even be helpful in that process of building up the experience to figure out which places are reputable for the thing that I'm trying to figure out. JOËL: Yeah, especially when there's a whole new landscape, right? You don't really know what are the places that have good information and the ones that don't. For some things, there might be, like, an obvious first place to start. So, recently, I was on a project where I was trying to do an integration between a Rails app and a Snowflake data warehouse. And so, the first thing I did—I'm not randomly Googling—I went to the Snowflake website, their developer portal, and started reading through documentation for things. Unfortunately, a lot of the documentation is a bit more corporatey and not really helpful for Ruby-specific implementation. So, there's a few pieces that were useful. There were some links that they had that sent me to some good places. But beyond that, I did have to drop to Google search and try to find out what kinds of other things the community had done that could be helpful. Now, that first pass, though, did teach me some interesting things. It gave me some good keywords to search for. So, more than just Ruby plus Snowflake or something like that like, I knew that I likely was going to want to do some kind of connection via ODBC. So, now I could say, okay, Ruby plus ODBC integration, or Ruby plus ODBC driver and see what's happening there. And it turns out that one of the really common use cases for ODBC and Ruby is specifically to talk to Snowflake. And one of the top results was an article saying, "Hey, here's how you can use ODBC to get your Rails app to talk to Rails." And then I knew I struck gold. STEPHANIE: That's really cool. The thing that I was picking up on in what you were saying is the idea of finding what is most relevant to you. And maybe that is something that the algorithm serves you because, like, it's, like, what a lot of people are searching for, you know, a lot of people are engaging with, or matching with all these keywords that you're using. My little hack that I've been [chuckles] using is to use Slack and lean on other people who have maybe a little more, even just, like, a little more experience than me on the subject, and seeing, like, what things they're linking to, and what resources they're sharing. And I've found that to be really helpful as a place to start. Because, at that point like, my co-workers are narrowing down the really broad landscape for me. JOËL: I really like how you're sort of you're redefining the question a little bit here. And that, I think, when we talk about search, there's almost this implicit assumption that search is going to be searching the public internet through Google or some other alternative search engine. But you're talking about actually searching from my private corpus of data, in this case, either thoughtbot or maybe the client's Slack conversations, and pulling up information there that might be much more relevant or much more specific to the work that you're trying to do. STEPHANIE: Yeah. In some ways, I like to think of it as crowd-sourced but, like, a crowd that I trust and, you know, know is relevant to me and what I'm working on. I actually have a fun fact for you. Did you know that Slack is actually an acronym? JOËL: No, I did not know that. What does it stand for? STEPHANIE: It stands for Searchable Log of All Communication and Knowledge. JOËL: That is incredibly clever. I wonder, is this the thing where they came up with that when they made the original name? Or did someone go back later on, you know, a few years into Slack's life and was like, you know what? Our name could be a cool acronym; here's an idea. STEPHANIE: I'm pretty sure it was created in Slack's early days. And I think it might have even helped decide that Slack was going to be called Slack as opposed to some of the other contenders for the name of the software. But I think it's very accurate. And that could just be how I use Slack. I'm a very heavy search power user in Slack. [laughs]. So, I find it very apt. You know, obviously, I use it a lot for finding conversations that happened. But I really do enjoy it as a source of discovery for a specific topic, or, you know, technical question or idea that I'm wanting to just, like, filter down a little bit beyond, like you said, the public internet. In fact, I have found it really useful for when you encounter errors that actually are specific to your domain or your app. Obviously like, you will probably be less successful searching in your search engine for that because it includes, you know, context from your app that other people in the world don't have. But once you are narrowing it down to people at your company, I've been able to get over a lot of troubleshooting humps that way by searching in Slack because likely someone within my team has encountered it before. JOËL: So, you mentioned searching for error messages in particular. And I feel like that is, like, its own, like, very specific searching skill separate from more general, like, how do I X-style questions. Does that distinction kind of line up with your mental map of the searching landscape? STEPHANIE: Yeah. I guess the way that I just talked about it now was potentially a bit confusing because I was saying instead of how you might search for errors normally, but I did not talk about how you might search for errors normally. [laughs] But specifically, you know, if I'm popping error messages into my search engine, I am removing the parts of the stack trace that are specific to my app, right? Because I know that that will only kind of, like, clutter up my query and not be getting me towards a more helpful answer as to the source of my issue, especially if the issue is not my application code. JOËL: Right. I want to give a shout-out to an article on the thoughtbot Blog with a wonderful name: Indiana Jones and the Crypt of Cryptic Error Messages by Louis Antonopoulos. All about how to take an error message that you get from some process in your console and how to make that give you results when you paste it into a search engine. STEPHANIE: I love that name. Very cool. JOËL: So, you've talked a little bit about the idea of searching some things that are not on the public internet. How do you feel about kind of internet knowledge bases, private wikis, that kind of thing? Have you had good success searching through those kinds of things? STEPHANIE: Hmm, I would say mixed success, to be honest. But that's because of maybe more so the way that a team or a company documents information. The reason I say mixed results is because, a lot of the time, the results are outdated, and they're no longer relevant to me. And it doesn't take that much time to pass for something to become outdated, right? Because, like, the code is always changing. And if, you know, someone didn't go and update the documentation about the way that a system has changed, then I usually have to take the stuff that I'm kind of seeing in private wikis with a bit more skepticism, I would say. JOËL: Yeah, I think my experience mirrors yours as well. Also, some private wikis have just become absolutely huge. And so, searches just return a lot of results that are not really relevant to what I'm searching for. The searching algorithms that these systems use are often much less powerful than something like Google. So, they often don't sort results in a way that are bringing relevant things up to the top. So, it's more work to kind of sift through all of the things I don't care about. STEPHANIE: Yeah, bringing up the size of a wiki and, like, all of the pages, that is a good point because I see a lot of duplicate stuff, but that's just, like, slightly different. So, I'm not sure which one I'm supposed to believe. One really funny encounter that I had with a private wiki, or actually it was, like, a knowledge base article that was for the internal team...it was documenting actually a code process. So, it was documenting in more human-readable terms, like the steps an algorithm took to determine some result. But the whole document was prefaced by, "This information came from an email that was sent way long ago." [laughs] JOËL: That's an epic start to a Wiki article. STEPHANIE: Yeah. And there was another really funny line that said, "The reason for this logic is because of a decision made by (This person's name.)," like a business decision that (some random person name). No last name either, so I have no idea [laughs] who they could be referring to and any of the, like, historical context of why that happened. But I thought it was really funny as just a piece of, like, an artifact, of, at the time, when this was written, that meant something to someone, and that knowledge kind of has been diluted [laughs] over the years. JOËL: Yeah, internal wikis, I feel like, are full of that, especially if they've had a few years to grow and the company has changed and evolved. So, now it's time for hot takes. STEPHANIE: Yeah, I'm ready for them. JOËL: We are now in the fancy, new age of AI. Is ChatGPT going to make all of this episode obsolete? STEPHANIE: I'm going to say no, but I'm also biased, and I'm not a ChatGPT enthusiast. I've said it on air. [laughs] I can't even say that I've used it. So, that's kind of where I'm coming from with all this. But I have heard from folks that, convenient as it may be, it is not always 100% accurate or successful. And I think that one of the things I really like about kind of having agency over my search is that I can verify, as a human, the information that I'm seeing. So, you know, when you're, like, browsing a bunch of Stack Overflow questions and you see, you know, all these answers, at least you can, like, do a little bit of, like, investigation using context clues about who is answering the question, you know, like, what experience might they have? If you encounter something on a blog post, for example, you can go to the about page on this person's blog and be like, who are you? [chuckles] And, like, what qualifies you to give this information? And I think that is really valuable for me in terms of evaluating whether I want to go down a path based on what I'm seeing. JOËL: So, I've played with it a tiny, little bit, so not enough to have a good sample size. And I think it can be interesting for some of those less constrained kind of how do I style questions. I'm not necessarily looking for, like, an exact code sample. But even if it just points me towards, oh, I need to be looking at this particular class in this standard library and read through that documentation to build the thing that I want. Or maybe it links me to kind of the classic blog posts that people refer to when talking about this thing. It's a good way sometimes to just narrow down when you're kind of faced with, you know, the infinity of the internet, and you're kind of like, oh, I don't even know where to start. It gives you some keywords or some threads to follow up on that I think can be really interesting. STEPHANIE: The infinity of the internet. I love that phrase. I don't think I've heard it before, but it's very evocative for me [laughs]. And I like what you said about it helping you give a direction and to kind of surface those keywords. In fact, it almost kind of sounds like what I was mentioning earlier about using Slack for, right? And, in that case, the hive mind that I'm pulling from is my co-workers. But also, I can see how powerful it would be to leverage a tool that is guiding you based on the software community at large. JOËL: Something I'd be curious to maybe lean into a little bit more are some of those slightly more specified questions where it does give you a code snippet, so something like writing a file to disk where, right now, it's, you know, five characters. I just pop up Alfred and type up Ruby F, and it gives you the file docs, and it's, you know, right there. There's usually an example at the top of the file. I copy-paste that and get working. But maybe this would be a situation where some AI-assisted tools would be better. It could be searching through something like ChatGPT. It could be maybe even something like Co-pilot, where, you know, you just start typing a little bit, and it just fills out that skeleton of, like, oh, you want to write a file to disk in Ruby. Here's how it's typically done. STEPHANIE: Yeah, you bring up a good point that, in some ways, even the approaches to searching we were talking about originally is still just building off of algorithms helping us to find what we're looking for, right? Though, I did really want to recommend an awesome talk from Kevin Murphy, from a RailsConf a couple of years ago, that's called Browser History Confessional: Searching My Recent Searches. The main message that I really enjoyed from this talk was the idea of thinking about what you're searching for and why because that will, I think, help add a bit of, like, intentionality into that process. You know, it can be very overwhelming, but let that guide you a little bit. One of the things that he mentions is the idea of revisiting your own assumptions with search. So, even if you think you know how to do something, or you might even know, like, how you might want to do it, just going to search to see if there's any other implementations that you haven't thought of that other people are doing that might inform how you approach a problem, or at least, like, make you feel even more confident about your original approach in the first place. I thought that was really cool. That's not something that I do now, but definitely, something that I want to try is to be, like, I think I know how to do this, but let me see what other people are doing because that might spark something new. JOËL: We'll put a link in the show notes to this talk. But I was lucky enough to see it in person. And also would like to second that recommendation. It is worth watching. From this conversation that you and I have had, I'm having, like, two main takeaways. One is kind of what you just said, the idea of being a little bit more cognizant of, what kind of search am I doing? Is this a sort of broad how do I X, where I don't even really know where to start? Is this, like, something really specific where you just don't know what kind of syntax you want to use? Is it an error message where you just want to see what other people have done when they've encountered this? Or any other, like, more specific subcategories. And how being aware of that can help you search more effectively. And secondly, don't limit yourself to the public internet. There's a lot of great information in your company's Slack or other instant messaging service, maybe some kind of documentation system internal, some kind of wiki. And those can be a great place to search as well. STEPHANIE: If we missed any other cool searching tips or tricks or ways that we might be able to improve our processes for searching as developers, I would really love to hear about them. So, if any listeners out there want to write in with their thoughts, that would be super awesome. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

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 (https://www.oofd.org/) Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_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? STEPHANIE: Yeah, I love that you asked that question because you're right; it is codified, literally, in the codebase. There are ownership files that are in the repo itself where they've specified, like, all of the models that a team owns, you know, down to the names of the files themselves, or maybe a namespace. It has the team name and all of the team members' handles. So, that's how it was able to tell me in an automated way, like, hey, reach out to these people. It was really interesting because it was pretty frictionless on my end, where all I had to do was see that, you know, I couldn't submit my pull request until I got that approval. But it was enough friction to be, like, well, you can't just, you know, change files in this domain without someone with extra context taking a look. JOËL: This reminds me a little bit of a system that GitHub has where you have this CODEOWNERS file that you can add to a repo. Have you messed around with that at all, or kind of seen how that looks? STEPHANIE: I have a little bit. I think I've only seen it in the context of being notified that someone is wanting to submit a pull request, but I'm not sure if it does gate merging based on ownership. Do you know if that's the case? JOËL: I don't. I think you can set it up to automatically request reviews from owners. And on a large repo, the owner could be...I assume this is based maybe on directories, or it might be a regex pattern. I forget the exact details. But you can have owners for partial parts of the code instead of owners of the entire repository. So, then, if you make a change to a particular part of the code, it would ping the correct person automatically to review your code, which sounds like a really nice feature. STEPHANIE: Yeah, absolutely. I think for the project that I'm working on, this definitely seemed like a custom process that they, at one point, decided to enforce. I'm not really sure about the history of how this came to be. But I found it actually quite a good way to meet people who are working in other parts of the codebase. The person who happened to be ambassador that I pinged was so helpful in just, you know, making sure that I kind of understood the parts of the code that they owned that were honestly, like, quite complex. Like, I would not have felt confident just going ahead and making those changes necessarily myself because this is a pretty legacy codebase. There are quite a few gotchas, and they were able to point some [laughs] of them out to me. Yeah, having that extra confidence was helpful for the particular feature I was working on. But it did also kind of give me a little pause because I've not worked at such a scale where there was so much uncertainty about the domain and that being so diffused across like I mentioned, hundreds of people. JOËL: Do you think that this ownership system that's in place helps manage the complexity of scaling up to a team of hundreds of developers? Or does it feel like it kind of just adds a lot of process that gets in your way? STEPHANIE: Ooh, that's a good question. It seems like kind of a chicken-and-the-egg situation because I felt better with someone else's input, right? Like, with someone else with more domain knowledge than me about what I was touching to be, like, "Yeah, like, this looks good to me," giving the plus one. Whereas if that didn't exist, maybe I would have tried to seek it out on my own. But I would not have known where to start, right? I would have to ask around and be like, "Hey, like, who has worked in this directory before?" or whatever. Or I could have just went ahead and merged my code and hope my lack of context didn't really cause any huge problems, like outside of what was covered by the tests. But this is helpful for, like, where the codebase is at, you know, and the size it has grown. JOËL: Do you think requiring an owner to review the code puts maybe an undue burden on the person who's the owner and that they might end up spending a lot of time reviewing code because they now kind of manage that part of the app? STEPHANIE: Yeah, that's a really good question. I think it can. But I also feel a little better that that role is rotated, that everyone on the team gets the opportunity to really, like, focus on that. And I'm pretty sure the way it works is that that is their main focus for the sprint, or the week, or whatever, and that they're not assigned any other feature work but to prioritize being that ambassador. So, in some ways, that is a lot of process, right? And there is that trade-off of having to allocate someone specific to answer people's questions. But at least from what I've seen, it does seem like a necessity because people do have questions, right? And I think they have figured out a system where it's very clear who you're supposed to talk to, and that accountability aspect of it has been met. Because I've also, like, worked on teams where that role is not well defined. People don't want to do it. And it's almost kind of a bystander effect where someone asks a question, but no one is specifically responsible for answering it, and so no one answers it. JOËL: Oh yeah. Yes. And then you get kind of the cost of the bureaucracy without the benefits of kind of diffusing that knowledge. So, we've been talking a lot about how this kind of ownership system can be really beneficial despite the overhead for a team that's 200 or 300 developers and where nobody knows all of the code or all of the nuances. And kind of at the other extreme, it's absolutely not worth it for a team of two or three developers where everybody knows the code, and there's kind of shared ownership of the project. Somewhere in between, there is where you start having maybe some of those conversations about scaling the team, and do we need to introduce more process? In your experience, where do you think introducing some sort of ownership system like this starts becoming valuable? Or maybe what are some of the questions that a team should ask themselves to gauge, like, at the size we're at right now, would we get value from an ownership system? STEPHANIE: Yeah, that's a really good point because as you were saying that, I was just starting to think of, yeah, I've certainly worked on projects where I have reviewed every piece of code that is to be merged, right? And then, at some point, that starts to change where, like, I can't do that anymore. And that transition has always been really interesting to me. And then, I think there is, like you mentioned, another one where it's like, okay, now we aren't able to review everything, but, like, how do we trust that the code that is being merged, even if we don't all share that same context, is up to the quality we want it or is bug-free? Because without that context, there's always the opportunity that something might be missed. I think I've seen that on teams, you know, really look like more bugs than usual, right? And maybe there is, like, actually, like, a big problem, and the site is down. And maybe there is, like, a post-mortem or something to discuss, like, why this happened. And, you know, it turns out that the siloing or, like, the lack of context sharing was partly involved. And so, I do think there are definitely symptoms when we're starting to firefight a little more [chuckles] that might be kind of an indicator that the app has grown to a point where some context is being lost, and there are not guardrails in place to do our best to, like, share it, like, when we can and not when it's too late. JOËL: Would it be fair to say that your recommendation is the team should not have an ownership system and kind of stick to everybody reviews all the code as they grow until they start hitting actual pain points, such as real bugs caused and, at that point, let that pain or maybe even the post-mortem be the thing that triggers the introduction of an ownership system? STEPHANIE: I think so. I have not seen something like that proactively introduced. I would be curious if anyone has experienced something like that. But, you know, I think it's okay for change to be a little painful, right? And that's part of the growing pains of becoming a larger team, or organization, or codebase and continuing to reevaluate. Though, I guess I would be a little cautious about, you know, jumping straight to introducing processes or policies, right? Because those can be really hard to undo if they end up not being actually helpful for the root cause of the problem. But, like, how you experimented with making sure that, you know, we didn't have any in-progress tickets for that project. The idea of just trying something and seeing how it works and kind of getting the team's feedback that is really valuable to me, at least as an IC. And, yeah, just making sure, like, you know, hearing from all of your team members on how those processes are changing the way they work and if it's feeling good or not. Like I said, I enjoyed the process on my client project because it helped me feel more confident that the code that I was changing...because I can't possibly gain all of the knowledge that the owners of that area of the code have. It's just not going to happen. But also, I can imagine it being maybe not so good for someone else, right? It kind of being a barrier or being frustrating because, oh no, they really need to merge the code. And maybe they made the smallest change in a file owned by another team, right? And having to jump through that hoop. JOËL: Yeah, that has absolutely never happened to me. STEPHANIE: Really? Because it sounds like it has. [laughter] JOËL: Yes, it absolutely has. We've been kind of throwing around the idea of ownership the idea of team almost interchangeably as if they're one-to-one. And I want to lean a little bit into this idea of the team. Because I think there's an implicit assumption here that, within a team, there's enough knowledge sharing that happens, enough shared context, that everybody can kind of understand all of the code for their team, and that knowledge is just shared around, so you don't need these extra processes within teams. But maybe once you start having multiple teams as part of your engineering department, then there starts to be some friction or some lost context that needs some mechanism to get around. Does that sound about right to you? STEPHANIE: Ooh, I think that depends because even within my team, we are working on different projects, and I am definitely not on top of, you know, what some other folks are working on. And even within our team, there are silos. The difference there, though, is that I know who they are. Like I still am in contact with them in our daily syncs, that the barrier to finding someone who has the right information is much lower. So, yeah, I think that is definitely a part of it, too, if, like...I think just the social barrier, even of, like, reaching out to someone you don't know and being like, "Hey, like, can you review my code?" that is [laughs] kind of...can be a little scary. And the dynamics definitely feel different within a team and between teams. JOËL: Yeah, and definitely just the idea of, like, someone you see every day for your daily sync, you're going to feel much more comfortable reaching out to them for help or for a quick review than to a total stranger. So, it's interesting that you mentioned the social aspects of things. I don't know if you're familiar with Conway's Law, the idea that the technical structures of our code, over time, end up reflecting the social structures of our teams. STEPHANIE: Yeah, that is something that makes a lot of sense on the project that I'm working on now, where the boundaries, like I mentioned, between teams and between different namespaces are semi-rigid, I suppose, right? Rigid enough that, you know, there is a process but not so high that it becomes a burden, at least in my opinion. But for another feature that I worked on, I actually had to interact with an external system that's owned more by the parent company of my current client. And that process was definitely more rigid. And I had to figure out who to email and had to, you know, look up this person's profile in the company directory to make sure that, you know, I was talking to the right person who had information that was relevant to me. And then, you know, even, like, the technical aspect of talking to this external service had a lot of various barriers and, you know, special authorization and configuration that I needed to set up. So, definitely felt that in terms of the different levels of ease and talking to systems owned by different parties. JOËL: So, the fact that there's, like, an actual, like, departmental or even, like, corporate boundary, definitely showed up in, like, a very hard boundary in the code as well. STEPHANIE: Yeah, absolutely. JOËL: And I think taking this to an extreme, I've seen this happen when teams want to introduce microservices. And oftentimes, the boundaries of those microservices are not necessarily driven entirely by technical reasons, but they're often by social reasons. So, we can say, hey, this team is going to own this service, and everybody else only needs to interact with a public API. And we can make all sorts of changes internally, and you never need to know that. They will never break your code. And also, we don't need to bother each other or feel the need to fully deeply understand the internals of each system. STEPHANIE: Yeah. Once you're introducing APIs that are accessible to a certain group of people and having to navigate, you know, making changes to the API or aligning in the expected structure of the, you know, communication that you're sending between them, that is definitely a pretty rigid boundary [laughs] and ends up being a lot of overhead to talk to those systems. And I certainly have been in the position of trying to communicate with the people who built and designed those systems and figuring out how to get on the same page. And even just recently, I was accidentally sending something as an array, and they were expecting it as a string. And that caused all these problems of making the request happen, you know, successfully. And we didn't even realize it until someone pulled out the doc that had the API schema and pointed out that there was some miscommunication along the way. JOËL: And that can be such a hard boundary around even, like, the idea of ownership. So, you were talking about how, earlier, when you were working in code that's maybe owned by another team, they might want to review it before it gets merged. So, there's a bit of a gatekeeping there. When a team transitions fully to microservices, I've seen it go almost, like, more extreme where it's even, like, you don't even change the code. You submit a ticket into our system. We will prioritize it, and then eventually, we will build your feature. But you don't even get to make a change to the code and have us approve it. We're going to make all that because we own it. So, it kind of feels like taking that ownership idea and then just really running to a full extreme. STEPHANIE: Yeah, right. That makes a lot of sense in the lens of Conway's Law if those are the processes they have in place for navigating cross-team collaboration or communication. Because, at some point, maybe they just reached a level where it had to be enforced that way because maybe things were getting dropped, or more casual lower barrier connection was too overwhelming or just not working for the organization. JOËL: I think what I've been hearing just now and then just more broadly throughout the episode is that while there's a lot of interesting technical solutions that can make things better, at its root, scaling a team is a social problem. And it's all about how your teams communicate with each other so that you can scale smoothly and that the system doesn't suffer from adding more people. STEPHANIE: Yeah. I think this is an area where I would love to hear any thoughts from our listeners about how their organizations handle something similar because I find all of this really interesting. And, you know, it ends up impacting my day-to-day work in a very real way. And so, if other places have figured out how that scaling and, you know, social and technical boundaries work in a way that feels good, I would love to know. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

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 (https://www.codegram.com/blog/understanding-class-instance-variables-in-ruby/) Build vs Buy by Josh Clayton (https://thoughtbot.com/blog/build-vs-buy-considerations-for-new-products) Sustainable Rails (https://sustainable-rails.com/) 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 open source because they are kind of, you know, really different solutions with different outcomes in terms of, you know, maintenance and dependencies, right? And that all have, like, a little bit of a different way to engage with them. JOËL: Interesting. I think I tend to think of the buy category, including both like commercial off-the-shelf software and also open-source off-the-shelf software, things that we wouldn't build custom for ourselves but that are third-party components that we can pull in. STEPHANIE: Yeah, that's interesting because I had a bit of a different mental model because, in my head, when you're buying a commercial solution, you, you know, are maybe losing out on some opportunities for customization or even, like, forking it on your own. So, with an open-source solution, there could be an aspect of making it work for you. Whereas for a commercial solution, you really become dependent on that other company and whether they are willing to cater [laughs] to your needs or not. JOËL: That's fair. For something that's closed-source where you don't actually have access to the code, say it's more of a software as a service situation, then, yeah, you're kind of locked in and hoping that they can provide the needs that you have. On the flip side, you are generally paying for some level of support. The quality of that varies sometimes from one vendor to another. But if something goes wrong, usually, there's someone you can email, someone you can call, and they will tell you how to fix the problem, or they will fix it on their end. STEPHANIE: For the purposes of this conversation, should we talk about the differences, you know, building yourself or leaning on an existing built-out solution for you? JOËL: The project I'm working on is integrating with a Snowflake data warehouse, which is an external place that stores data accessible through something SQL-like. And one of the things that's attractive about this is that you can pull in data from a variety of different sources, transform it, and have it all stored in a kind of standardized structure that you can then integrate with. So, for pulling data in, you can build your own sort of ingestion pipeline, if you want, with code, and their APIs, and things. But there are also third-party vendors that will give you kind of off-the-shelf components that you can use for a lot of popular other data sources that you might want to pull. So, you're saying; I want to pull from this external service. They've probably got a pre-built connector for it. They can also do things like pull from an arbitrary Postgres database on some other server if that's something you have access to. It becomes really attractive because all you need to do is create an account on this website, plug in a few, like, API keys and URLs. And, all of a sudden, data is just flowing from one third-party system into your Snowflake data Warehouse, and it all just kind of works. And you don't have to bother with APIs, or ODBC, or any of that kind of stuff. STEPHANIE: Got it. Yeah, that does sound convenient. As you were talking about this, I was thinking about how if I were in the position of trying to decide how to make that integration happen, the idea of building it would seem kind of scary, especially if it's something that I don't have a lot of expertise in. JOËL: Yeah, so this was really interesting. In the beginning of the project, I looked into a little bit of what goes into building these, and it's fairly simple in terms of the architecture. You just need something that writes data files to typically something like an S3 bucket. And then you can point Snowflake to periodically pull from that bucket, and you write an import script to, you know, parse the columns and write them to the right tables in the structure that you want inside Snowflake. Where things get tricky is the actual integration on the other end. So, you have some sort of third-party service. And now, how do you sort of, on a timer maybe, pull data from that? And if there are data changes that you're synchronizing, is it just all append-only data? Or are you allowing the third-party service to say, "Hey, I deleted this record, and you should reflect that in Snowflake?" Or maybe dealing with an update. So, all of these things you have to think about, as well as synchronization. What you end up having to do is you probably boot up some kind of small service and, you know, maybe this is a small Ruby app that you have on Heroku, maybe this is, like, an AWS Lambda kind of thing. And you probably end up running this every so many seconds or so many minutes, do some work, potentially write some files to S3. And there's a lot of edge cases you have to think about to do it properly. And so, not having to think about all of those edge cases becomes really enticing when you're looking to potentially pay a third party to do this for you. STEPHANIE: Yeah, when you used the words new service, I bristled a little bit [laughs] because I've definitely seen this happen maybe on a bit of a bigger scale for a tool or solution for some need, right? Where some team is formed, or maybe we kind of add some more responsibilities to an existing team to spin up a new service with a new repo with its own pipeline, and it becomes yet another thing to maintain. And I have definitely seen issues with the longevity of that kind of approach. JOËL: The idea of maintaining a fleet of little services for each of our integrations seemed very unappealing to me, especially given that setting something like this up using the commercial approach probably takes 30 minutes per third-party service. There's no way I'm standing up an app and doing this whole querying every so many minutes, and getting data, and transforming it, and writing it to S3, and addressing all the edge cases in 30 minutes. And it's building something that's robust. And, you know, maybe if I want to go, like, really low tech, there's something fun I could do with, like, a Zapier hook and just, like, duct tape a few services together and make this, like, a no-code solution. I still don't know that it would have the robustness of the vendor. And I don't think that I could do it in the same amount of time. STEPHANIE: Yeah. I like the keyword robustness here because, at first, you were saying, like, you know, this looked relatively small in scope, right? The code that you had to write. But introducing all of the variables of things that could go wrong [laughs] beyond the custom part that you actually care about seemed quite cumbersome. JOËL: I think there's also, at this point, a lot of really interesting prioritization questions. There are money questions, but there are also time questions you have to think about. So, how much dev time do we want to devote upfront to building out these integrations? And if you're trying to move fast and get a proof of concept out, or even get, like, an MVP out in front of customers, it might be worth paying more money upfront to a third-party vendor because it allows you to ship something this week rather than next month. STEPHANIE: Yeah. The "How soon do you need it?" is a very good question to ask. Another one that I have learned to include in my arsenal of, you know, evaluating this kind of stuff comes from a thoughtbot blog by Josh Clayton, where he, you know, talks about the build versus buy problem. And his takeaway is that you should buy when your business is not dependent on it. JOËL: When it's not part of, like, the core, like, value-add that your business is doing. Why spend developer time on something that's not, like, the core thing that your product is when you can pay someone else to do it for you? And like we said earlier, a lot of that time ends up being sunk into edge cases and robustness and things like that to the point where now you have to build an expertise in a, like, secondary thing that your business doesn't really care about. STEPHANIE: Yeah, absolutely. I think this is also perhaps where very clear business goals or a vision would come in handy as well. Because if you're considering building something that doesn't quite support that vision, then it will likely end up continuing to be deprioritized over the long term until it becomes this thing that no one is accountable for maintaining and caring for. And just causes a lot of, honestly, morale issues is what I've seen when some service that was spun up to try to solve a particular problem is kind of on its last legs and has been really neglected, and no one wants to work on it. But it ends up causing issues for the rest of the development team. But then they're also really focused on initiatives that actually do provide the business value. That is a really hard balancing act that I've seen teams struggle with. JOËL: Earlier this year, we were talking about the book Sustainable Rails. And it really hammers home the idea of a carrying cost for the code, and I think that's exactly what we're talking about here. And that carrying cost can be time and money. But I like that you also mentioned the morale effects. You know, that's a carrying cost that just sort of depresses the productivity of your team when morale is low. STEPHANIE: Yeah, absolutely. I'm curious if we could discuss some of the carrying costs of buying a solution and where you've seen that become tricky. JOËL: The first thing to look at is the literal cost, the money aspect of things. And I think it's a really interesting situation for the business models for these types of Snowflake connectors because they typically charge by the amount of data that you're transmitting, so per row of data that you're transmitting. And so, that cost will fluctuate depending on whether the third-party service you're integrating with is, like, really chatty or not. When you contrast that to building, building typically has a relatively fixed cost. It's a big upfront cost, and then there's some maintenance cost to go with it. So, if I'm building some kind of integration for, let's say, Shopify, then there's the cost I need to build up front to integrate that. And if that takes me, I don't know, a week or two weeks, or however long it is, you know, that's a pretty big chunk of time. And my time is money. And so, you can actually do the math and say, "Well, if we know that we're getting so many rows per day at this rate from the commercial vendor, how many weeks do we have to pay for the commercial one before we break even and it becomes more expensive than building it upfront, just in terms of my time?" And sometimes you do that math, and you're like, wow, you know, we could be going on this commercial thing for, like, two years before we break even. In that case, from a purely financial point of view, it's probably worth paying for that connector. And so, now it becomes really interesting. You say, okay, well, which are the connectors that we have that are low volume, and which are the ones that are high volume? Because each of them is going to have a different break-even point. The ones that you break even after, you know, three or four weeks might be the ones that become more interesting to have a conversation about building. Whereas some of the others, it's clearly not worth our time to build it ourselves. STEPHANIE: The way you described this problem was really interesting to me because it almost sounds like you found the solution somewhere in the middle, potentially, where, you know, you may try building the ones that are highest priority, and you end up learning a lot from that experience, right? That could make it easier or at least, like, set you up to consider doing that moving forward in the future if you find, like, that is what is valuable. But it's interesting to me that you kind of have the best of both worlds of, like, getting the commercial solutions now for the things that are lower value and then doing what you can to get the most out of building a solution. JOËL: Yeah. So, my final recommendation ended up being, let's go all commercial for now. And then, once we've built out something, and because speed is also an issue here, once we've built out something and it's out with customers, and we're starting to see value from this, then we can start looking at how much are we paying per week for each of these connectors? And is it worth maybe going back and building our own for some of these higher-volume connectors? But starting with the commercial one for everything. STEPHANIE: Yeah, I actually think that's generally a pretty good path forward because then you are also learning about how you use the commercial solution and, you know, which features of it are critical so that if you do eventually find yourselves, like, maybe considering a shift to building in-house, like, you could start with a more clear MVP, right? Because you know how your team is using an existing product and can focus on the parts that your business are dependent on. JOËL: Yeah, it's that classic iterative development style. I think here it's also kind of inspired by a strategy I typically use for performance, which is make it work before you try to make it fast. And, actually, make it work, then profile, then measure, find the hotspots, and then focus on making those things fast. So, in this case, instead of speed, we're talking about money. So, it's make it work, then profile, find the parts that are expensive, and make the trade-off of, like, okay, is it worth investing into making that part less expensive in terms of resources? STEPHANIE: I like that as a framework a lot. JOËL: A lot of what we do as programmers is optimization, right? And sometimes, we're optimizing for execution time. Sometimes we're optimizing for memory cost, and sometimes we're optimizing for dollars. STEPHANIE: Yeah, that's really interesting because, with the buy solution, you know very clearly, like, how much the thing will cost. Whereas I've definitely seen teams go down the building route, and it always takes longer than expected [laughs], and that is money, right? In terms of the developer's time, for sure. JOËL: Yeah, definitely, like, add some kind of multiplier when you're budgeting out that build alternative because, quite likely, there are some edge cases that you haven't thought about that the commercial partner has, and you will have to spend more time on that than you expected. STEPHANIE: Yeah, in addition to whatever opportunity cost of not working on something that is driving revenue for the business right now. JOËL: Exactly. STEPHANIE: So, the direction of this conversation ended up going kind of towards, like, what is best for the team at, like, a product and company level. But I think that we make these decisions a lot more frequently, even when it comes to whether we pull in a gem or, you know, use an open-source tool or not. And I would be really interested in discussing more of that in another episode. JOËL: Yeah. That gets into some controversial takes, right? It's the evergreen topic of: do we build it ourselves, or do we pull in some kind of third-party package? STEPHANIE: Something for the future to look forward to. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeee!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

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

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 (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) Javascript falsiness rules (https://www.sitepoint.com/javascript-truthy-falsy/) 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 things that was really frustrating, you know when you feel really confident that you know what you're doing. You're just writing a conditional statement. And it turns out the language beguiled you. [laughs] JOËL: I've run into similar bugs when I'm reading from environment variables because environment variables are always strings. But it's common that you'll be setting some kind of flag. So when you're setting the environment variable, you're setting something to true or false. But then, when you're reading it, you have to explicitly check if this environment variable double equals the string true, then do the thing. Because if you just check for the value, it will never be false. STEPHANIE: Right. And I kind of hate seeing code like that. I don't know; something about it just rubs me the wrong way because it just seems so strange, I suppose. JOËL: Is it just, like, those edge cases where you specifically have to do some kind of, like, double equals check on a value that feels like it should be a Boolean? Or do you kind of feel a bit weird about the concept of truthiness in general? STEPHANIE: I think the concept of truthiness is very hard to grasp sometimes. And, you know, when you're talking about that edge case where we are setting...we're checking if the string is the string true. That means that everything else is false, right? So, in some ways, I think it's just really confusing because we've expanded the definition of what true and false mean to be anything. JOËL: That's really interesting because now you have to pick. Are you checking against the string true, or are you negatively checking against the string false? And those are not equivalent because, like you said, now you're excluding every other string. So, is the string "Hello, World" put you in the false branch or the true branch? STEPHANIE: Who's to say? [laughs] I think a similar conundrum also occurs when we use predicate matchers in our tests. I think this is a gripe that I've talked about a little bit with others when we're writing tests and especially if we're writing a predicate method, and then that's what we're testing, right? We kind of are expecting a true or false value. And when our test expects something to be truthy rather than explicitly saying that we expect the return value to be true, that is sometimes a bit confusing to me as well because someone could theoretically change this method and just have it return "Hello, World," like you said, as a string, like, anything else. And that would still pass the test. JOËL: And it might even pass your code in most places. STEPHANIE: Right. And I suppose that's okay. Is it okay? I don't know. I'm not sure where I land on this. JOËL: I used to be a kind of hardcore Boolean person. STEPHANIE: [laughs] That's a sentence no one has ever [laughs] said. JOËL: I like my explicit trues and falses. I don't like the ambiguity of saying, like, oh, if person do a thing, it's, like, oh, what is person here? Is this a nil check? Is it explicitly false? Do you just want to know that this person is non-empty? Well, what exactly are you checking? So I like the explicitness of saying, oh, if person dot present, or if person dot empty, or if person dot nil. And I think maybe spending some time in some more strongly typed languages has also kind of pushed me a little bit in that direction, where it's nice to have something that is explicitly either just true or just false. And then you completely eliminate that problem of, like, oh, but what if it's neither true nor false, then what do we do for that branch there? And the answer is your compiler will reject that program or say, "You've written a bad program." And you never reach that point where there's a bug. I've slowly been softening my stance. A fellow thoughtbot colleague has written an article why there is no such thing as a Boolean in Ruby. Everything is just shades of gray and truthiness and falsiness. But from the perspective of a program, there is no such thing as a Boolean. And that really opened my eyes to a different perspective. I don't know that I fully agree, but I'm kind of begrudgingly acknowledging that Mike makes a good point. STEPHANIE: Yes, I read the blog post that he wrote about this exact problem. And I think it's called "Booleans Don't Exist in Ruby." And I think I similarly, like, came away with, like, yeah, I think I get it if I just suspend my disbelief, you know, hard enough. [laughs] But what you were saying about, like, liking the explicitness, right? And liking the lack of ambiguity, right? Because when you start to believe that Booleans don't exist, I think that really messes with your [laughs] head a little bit. And one takeaway that I got from that blog post, kind of like we mentioned earlier, is that there is such thing as false, and then everything else is true. And I guess that's kind of how Ruby operates. JOËL: Sort of, because then you have the problem of nil, which is also falsy. STEPHANIE: That's true, but nil is nothing. [laughs] JOËL: That's one of the classic problems as well when you're trying to do a nil check, or maybe some memoization, or maybe even, say, cache this value, or store this value, or initialize this value if it's not set. And assuming that doing nil is falsy, so you'll do some kind of, like, or equals, or just some kind of expression with an or in it thinking, oh, do this extra work if it's nil because then it will trigger the branch. But that all breaks down if potential for your value to be false because false and nil get treated the same in conditional code. STEPHANIE: Right. I think this could be a whole separate conversation about nil and the idea of nothingness. But I do think that, as Ruby developers, at least in the Ruby world, based on what I've seen, is that we lean on nil in ways that we maybe shouldn't. And we end up having to be very defensive about this idea of nil being falsy. But that's because we aren't necessarily thinking as hard about our return values and what our arguments are that; it ends up causing problems in evaluating truthiness when we're having to check those objects that could be nil. JOËL: In terms of the way we communicate with the readers of our code, and, as a reader, I generally assume that a Ruby method that ends with a question mark will return a true Boolean, either true or false. Is that generally your expectation as well? STEPHANIE: I want to say yes, but I've clearly experienced enough times where that's not the case that, you know, it's like, my ideal world and then reality [laughs] and having to figure out how to hold both of those things. JOËL: It's one of those things that's mostly true. STEPHANIE: I want to believe it because predicate methods and, like, the Ruby Standard Library mostly return Boolean values, at least to my knowledge. And if we all kind of followed that [laughs] pattern, then it would be clear. But I think there's a part of me that these days mostly believes it to be true that I will be getting a Boolean value (And, wow, even as I say this, I realize how confusing [laughs] this is starting to sound.) and that until I'm not, right? Until I'm surprised at some point. JOËL: I think there's two things I expect of predicate methods in Ruby. One is that they will return, like, a hard Boolean, either true or false. The second is that they are purely query methods; they don't do side effects. Neither of those are consistent across the ecosystem. And a classic example of violating that second guideline I have in my mind is the valid question mark method from Rails. And this really surprised me the first time I tripped into this because when you call that on an object, it doesn't just tell you whether or not the object is valid. It actually mutates the underlying object by populating the error messages' hash. So if you have an invalid object and you examine its error messages' hash, it will be empty until you call the valid question mark method. So sometimes, you don't even care about the return value. You're just calling valid to mutate the object so that you can access the underlying hash, which is that's weird code when you call a predicate method but then totally ignore the output. STEPHANIE: Yeah, that is strange because I have definitely seen it where we are calling the valid method to validate, and then we end up using the error messages that are set on that object later. I think that's tough because, in some ways, you do care about whether the object is valid or not. But then also, the error messages are helpful usually and when you're trying to use that method. The point is to validate it so that you can hopefully, like, tell the user or, like, the consumer of your system, like, what's wrong in validation. But it is almost, like, two separate things. JOËL: It is. And sometimes, it's really hard to split those two apart. So I'm not throwing shade at the Rails dev team here. Some of these design decisions are legitimately difficult to make. And what's most useful for the most people the most time is often a compromise. I think you brought up the idea of separating those two things. And I think there's a general principle here called command-query separation. That's, like, the fancy way of talking about what you were saying. STEPHANIE: One thing that I was just thinking about kind of when we initially picked off this conversation was the idea of how things outside the Ruby ecosystem or the Ruby world interact with what we're returning in terms of Boolean values. And so when I mentioned the object being serialized because of, you know, our database and, like, background job system, that's an entity that's figuring out what to do with the things that we are returning from Ruby. And similarly, when you're talking about environment variables, it's like, our computer system talking to now our language and those things being a bit different. Because when we, like, suspend our disbelief about what is truthy or falsy in Ruby, at least we're doing it in, like, the world of Ruby. And as soon as we have to interact with something else, like, maybe that's when things can get a little hairy because there's different ideas about truthiness there. And so I'm kind of also thinking about what we return in APIs and maybe, like, that being an area where some explicitness is more required. JOËL: Whenever I'm consuming third-party data, I'm a big fan of having some kind of transformation or parse step. This is inspired in part by the "Parse, Don't Validate" article, which I'll link in the show notes. So, if I'm reading data from a third-party API and I want it to be a Boolean, then maybe I should do the transformation myself. So maybe I check literally, is it the string true or the string false, and anything else gets rejected? Maybe I have...and maybe I'm a little bit more permissive, where I also accept capital T or capital F, and I have, like, some rules for transforming that. But the important thing is I have an explicit conversion step and reject any bad output. And so for something like an environment variable, maybe that would look like looking for true or false and raising if anything else is there. So that we try to boot the app, and it immediately crashes because, hey, we've got some, like, undefined, like, bad configuration that we're trying to load the app with. Don't even try to keep running. Hard crash immediately. Fix it, and then come back. STEPHANIE: Yeah, I like that a lot because the way we ended up fixing this issue with the background job that I mentioned was just coercing our string value into a Ruby Boolean in the job that we were then, like, running the conditional in. But really, what we should have done is have fixed that at a higher level and where we parse and deserialize, like, the values we're getting from the job to prevent this kind of in the future because right now, someone can do this again, and that's a real bummer. JOËL: I always love those deeper conversations that happen after you've had a bug that are like, how do we prevent this from happening again? Because sometimes that's where you have the deepest learnings or the most interesting insights or, you know, ideas for Bike Shed episodes. I'm really curious to contrast JavaScript's approach to truthiness to Ruby's because even though they both use the same idea, they kind of go about it differently. STEPHANIE: Tell me more. JOËL: So, in Ruby, an empty array and an empty string are truthy. JavaScript decided that empty things are falsy. And I forget...there's a whole table that shows the things that are truthy and falsy in JavaScript. I want to say zero is falsy in JavaScript but don't quote me on that, which can also lead to some interesting edge cases you have to think about. STEPHANIE: Okay, yes. This is coming back to me now. I think depending on what, you know, ecosystem or language or world I'm in, I have to just only be able to think about what is true in this world [laughs] and then do that context switching when I am working in something else. But yeah, that is a really interesting idea. Someone decided [laughs] that this was their idea of true or false. JOËL: I'm curious if you have a preference for sort of JavaScript's approach to falsiness where a lot more types of values are falsy versus Ruby, which said pretty much only nil and false are falsy. Everything else is truthy. STEPHANIE: Hmm, that is an interesting question. JOËL: Because in Ruby then or, I guess, in Rails, we end up with the present predicate method that is specifically checking for not only nil and false but also for empty array, empty string, those kinds of things. So, if you find yourself writing a lot of present matchers in your code, you're kind of leaning on something that's closer to JavaScript's definition of falsiness than Ruby's. But maybe you're making it more explicit. STEPHANIE: Right. In JavaScript, I see a lot of double bangs in lieu of those predicate methods. But I suppose by nature of having to write those predicate methods in Ruby, we're, like, really wanting something else, I think. And maybe...I guess it is just a question of explicitness like you're saying, and which I prefer. Is it that I need to be explicit to convey the idea that I want, or is it nice that the language has just been encoded that way for me? JOËL: Or maybe when you write conditionals, if you find yourself doing a lot of presence checks, do you find that you typically are trying to branch on if not null, not false, not empty more frequently than just if not null, not false? Because that's kind of the difference between Ruby's model and JavaScript's model. STEPHANIE: Hmm, the way you posed that question is interesting because it makes me think that sometimes it's quite defensive because we have to check for all these possible return values. We are unsure of what we are getting back. And so this is kind of, like, a catch-all for things that we aren't really sure about. JOËL: Yeah, I mean, that's the fun of dynamic programming languages. You never know exactly what you're going to get as long as things respond to certain methods. You really lean into the duck typing. And I think that's Mike's argument in his article that "Booleans Don't Exist" in that as long as something is responding to methods that you care about, it doesn't matter if you're dealing with a true Boolean or some kind of other value. STEPHANIE: Right. So I suppose the ideas of truthiness then are a little bit more dependent on how people are using the language though it seems like a chicken-and-egg situation to me. [laughs] JOËL: It is really interesting to me in terms of maybe thinking about use cases in my own code if I'm having to...if I'm writing code that leans on truthiness where I can say just, you know if user. But then knowing that, oh, that doesn't account for, like, an empty value. Do I then also need to add an extra check for emptiness? And maybe if I'm in a Rails project, I would reach for that present matcher where I wouldn't have to do that in JavaScript because I can just say, if user, and that already automatically checks for presence. So I'm kind of wondering now in my mind, like, which default would fit my use cases more? Or, if I go back to an older version of myself, I will say I don't want any of these defaults. They're all too ambiguous. I'm going to put explicitly if user dot nil question mark, if that's the thing that I'm checking for, or if user dot empty question mark because I want my reader to know what condition I'm checking. STEPHANIE: Yeah, that is interesting, this idea of, like, which mode do you find yourself needing to use more and if that is accommodated for you because that's just the more common, like, use case or problem. I think that's something that I will be thinking about the next time I write a conditional [laughs] because, like I was saying earlier, I think I end up just leaning on what someone else has decided for me in terms of truthiness and not so much how I would like it to work for me. JOËL: And sometimes we don't want to fight the language too much, you know if I'm writing Elm, that everything is hard Booleans. And I know I'm never going to get a nil in a place where I'd expect true or false because the compiler would prevent that from happening. I know that I'm not going to get an empty value, potentially. There's ways you can do things with a type system where you can explicitly say no empty values are even allowed at this point. And if you do allow them, then the type system will say, "Hey, you forgot to check for the empty case. Bad program. I'm rejecting that." And then you have to write that explicit branch for, oh, if empty versus if present. So I really appreciate that style of programming. But then, when you're in a language like Ruby where you're not dealing with explicit types on purpose, how do you shift that mindset so that you don't need to know the type of the value that you're dealing with? You only want to say, hey, in this context, here's the minimal interface that I want it to conform to. And maybe it's just the truthy or falsiness interface, and everything beyond that is not relevant. STEPHANIE: I think it's kind of wild to me that this idea of a binary that theoretically seems very clear turns out is actually quite confusing, ambiguous, philosophical, even. [chuckles] JOËL: Yeah. It's definitely...you can get into some deep, philosophical questions there, language design as well. One aspect, though, that I'm really curious about your thoughts is bringing new people in who are learning a language. It's really common for people who are learning a language for the first time, learning to code for the first time to write code that you and I would immediately know, like, that's not going to work. You can't add a Boolean and a number. You're just learning to code. You've never done that before. You don't know. And then how the language reacts to that kind of thing can help guide that experience. So, do you think that truthiness maybe makes things more confusing for newcomers? Or, maybe on the other side, it helps to smooth that learning curve because you don't have to be like, oh, wait, I have a user here. I can't put that in a condition because that's not a strict true or false. I'm going to coerce it, or I've got to find a predicate method or something. You can just be like, no, put it in. The interpreter will figure it out for you. STEPHANIE: Wow. That's a great question. I'm trying to put myself in the beginner's mindset a little bit and think about what it's like to just try something and the magic of it working. Because, like you said, the interpreter does it for you, or whatever, and something happens, and you're like, wow, like, that was really cool. And I didn't have to know all of the ins and outs of the types of things I was working with. That can be really helpful in just getting them, like, started and getting them just, like, on the ground writing code. And having that feeling of satisfaction that, like, that they didn't have to, you know, have to learn all these things that can be really scary to make their program work. But I do think it also kind of bites them later once they really realize [laughs] what is going on and the minute that they get that, like, unexpected behavior, right? Like, that becomes a time when you do have to figure out what might be going on under the hood. So two sides of the same coin. JOËL: What you're saying there about, like, maybe smoothing that initial curve but then it biting them later got me thinking. You know how we have the concept of technical debt where we write code in a way that's maybe not quite as clean today so we can move faster but that then later on we have to pay it back? And I almost wonder if what we have here is almost like a pedagogical debt where it's going to cost us a month from now, but today it helps us move faster and actually kind of get that momentum going. STEPHANIE: Pedagogical debt. I like that. I think you've coined a new term. Because I really relate to that where you learn just enough to do the thing now. But, you know, it's probably not, like, the right way or, like, the most informed—I think most informed is probably how I would best describe it—way of doing it. And later, you, yeah, just have to invest a little more into it. And I think that's okay. I think sometimes I do tend to, like, beat myself up over something down the line when I have to deal with some piece of less-than-ideal code that I'd written earlier. Like, I think that, oh, I could have avoided this if only I knew. But the whole point is that I didn't know. [laughs] And, like, that's okay, like, maybe I didn't need to know at the time. JOËL: Yeah, and code that's never shipped is of zero value. So having something that you could ship is better than having something perfect that you didn't ship. STEPHANIE: On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Stephanie just got back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. Joël started a new project at work. Review season is upon us. Stephanie and Joël think about growth and goals and talk about reviews: how to do them, how to write them for yourself, and how to write them for others. Blue Ridge Ruby (https://blueridgeruby.com/) Impactful Articles of 2022 (https://www.bikeshed.fm/369) Constructive vs Predicative Data by Hillel Wayne (https://www.hillelwayne.com/post/constructive/) Parse, don't validate by Alexis King (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) Working Iteratively (https://thoughtbot.com/blog/working-iteratively) thoughtbot's 20th Anniversary Live AMA (https://thoughtbot.com/events/ama-developers-20th-anniversary) 20th Anniversary e-book (https://thoughtbot.com/resources/20-for-20) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And, together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: I just came back from a smaller regional Ruby Conference, Blue Ridge Ruby, in Asheville, North Carolina. And I had a really great time. JOËL: Oooh, I'll bet this is a great time of year to be in Asheville. It's The Blue Ridge Mountains, right? STEPHANIE: Yeah, exactly. It was perfect weather. It was in the 70s. And yeah, it was just so beautiful there, being surrounded by mountains. And I got to meet a lot of new and old Ruby friends. That was really fun, seeing some just conference folks that I don't normally get to see otherwise. And, yeah, this was my second regional conference, and I think I am really enjoying them. I'm considering prioritizing going to more regional conferences over the ones in some of the bigger cities that Ruby Central puts on moving forward. Just because I really like visiting smaller cities in the U.S., places that I otherwise wouldn't have as strong of a reason to go to. JOËL: And you weren't just attending this conference; you were speaking. STEPHANIE: I was, yeah. I gave a talk that I had given before about pair programming and nonviolent communication. And this was my first time giving a talk a second time, which was interesting. Is that something that you've done before? JOËL: I have not, no. I've created, like, a new bespoke talk for every conference that I've been at, and that's a lot of work. So I love the idea of giving a talk you've given before somewhere else. It seems like, you know, anybody can watch it on the first time on YouTube, generally. But it's not the same as being in the room and getting a chance for someone to see you live and to give a talk, especially at something like a regional conference. It sounds like a great opportunity. What was your experience giving a talk for the second time? STEPHANIE: Well, I was very excited not to do any more work [chuckles] and thinking that I could just show up [chuckles] and be totally prepared because I'd already done this thing before. And that was not necessarily the case. I still kind of came back to my talk after a few months of not looking at it for a while and had some fresh eyes, rewrote some of the things. I was able to apply a few things that I had learned since giving it the first time around, which was good, just having more perspective and insight into the things that I was talking about. Otherwise, the content didn't really change, just polished it further. I think in the editing process, you could edit forever, really. So I imagine if I revisit it again, I'll find other things that I want to change. But this time around, I also memorized my slides because, last time, I was a little more dependent on my speaker notes. And part of what I wanted to do this time around, because I had a little more time in preparing, was trying to go from memory. And that went pretty well, I think. JOËL: How did you feel about the delivery of it? Because now you had a chance to have a practice run in front of a real audience. And, as much as you practice at home in front of the mirror, it's not the same as actually giving a talk in front of an audience. STEPHANIE: Yeah. I was surprised by how the audience is also different, and the things that they'll react to is slightly different. There were some jokes that landed similarly and others that didn't land a little bit with this crowd, but maybe other parts, there was more of a reaction. So that was surprising. And I think I had to kind of adjust those expectations on the fly as I delivered whatever, you know, line I was kind of expecting some kind of reaction to. And I also, other than memorizing my slides, you know, I think had the mental capacity to focus a little more on the delivery component that you're talking about because I wasn't, you know, up until the last minute still working on the content itself, and just being able to direct my mental energy to, I guess, the next level of performance when giving a presentation. And, yeah, I would definitely give this talk again. I really liked that it was something that feels pretty evergreen, something I care a lot about. I don't think it will be a topic that I get kind of bored of anytime soon. So those were all some of the things I was thinking about in giving a talk a second time. JOËL: When you write your speaker notes, do you give yourself directions for expected audience reactions, so something like a pause for laughter after a joke or something like that? STEPHANIE: No. I think I am too nervous about presuming [laughs] how the audience will react to put something in and then have to be, like, super surprised and figure out what to do if they don't react the way that I think they will. So it ends up being that I just kind of go forth. And if I do get a reaction out of them, that's great. But not expecting it works for me because then, at least, I can control how I am presenting and how I'm showing [chuckles] up a little bit more. JOËL: So you're really working with the energy in the room then. STEPHANIE: Yeah, I think so. JOËL: Was this talk recorded? So if people in the audience want to go and watch this talk. STEPHANIE: Yeah. The first version that I gave of it is online if you search for the title "Empathetic Pair Programming with Nonviolent Communication." And this version was recorded as well. So, eventually, it'll also be up. And, I don't know, maybe I'll watch it back and [chuckles] see the difference in presentation. I would be very curious. I've never watched any one of my conference talks fully through the recording from start to end before. But I know that that's something that I could continue to improve on. So maybe one day I'll find the confidence. My other highlight that I wanted to share about this regional conference is how well-organized it was. So it was mainly organized by Jeremy Smith, and I thought he did such an awesome job. He organized a bunch of activities in Asheville for the Saturday after the conference if folks wanted to stay a little longer and just check out the city. There was a group that went hiking, a group that did a brewery tour. And the activity I chose to do was to go tubing. JOËL: Fun. STEPHANIE: Yeah, it was my first time. So you're basically in an inner tube floating down a very calm river, just hanging out. You...we were on the group, and you could clip yourself to the rest of the group so you're all, you know, kind of floating down together. But some people would unclip themselves and just go free for a little while. And, yeah, when you get too hot, you can dip into the water to cool off. And I just had such a great time. [laughs] It was almost like being on a Disney ride but out in nature, which I just, like, is totally my jam. JOËL: I tried tubing once in Texas. And the inner tubes are black, and in the Texas sun, they get really hot. So every, I don't know, 20 minutes or so, I had to get off the inner tube. It was too hot to sit on. And I had to flip it just because it absorbed so much heat. STEPHANIE: Wow. Yeah, that does sound like it would get very hot. I think the funny thing that I wasn't expecting was how hard it would be to get back into the inner tube after you had gotten in the water, at least for me, because the inner tubes were quite large. And so I couldn't get enough leverage to pull myself [laughs] back up onto it, and ended up several times just, like, flopping belly first into the inner tube and then having to, like, flop over so that I could be on my back and be sitting in it again. And other times that I had to wait a little while until the river got shallower so I could actually stand and just sit in it. So there were times that it was kind of a struggle, but 90% of it was very chill and fun. So, Joël, what's new in your world? JOËL: I started a new project at work. I'm working with a data warehouse, pulling data in from a variety of sources, getting it all into one kind of unified schema, doing some transformations on it. And then also setting up some sort of outgoing plugins to allow different sources to access that unified data. So this is not in a Rails app, but we do have a Rails app connecting to this data warehouse. Data engineering is, at least in this style, is newer to me. So I think it's a really interesting world to get into. I don't know if, technically, this counts as big data. I don't think the term is cool anymore. But five or so years ago, everybody was all about the big data, and that was the hip term to toss around. STEPHANIE: So, is this something pretty new to you? You haven't had too much experience doing this kind of data engineering work before? JOËL: Yeah, at least not with, like, a data warehouse. I think a lot of the work around data transformations, or creating unified schemas, thinking in terms of data in different stages that are at different levels of correctness...I've done a fair amount of ETL, Extract, Transform, Load, or sometimes people shift it around and say, ELT, Extract, Load, Transform. I've done a fair amount of those because I've done a lot of integrations with third-party systems. STEPHANIE: So I've always thought of data engineering as, in some ways, a separate role or a track. And I'm really curious about you having, you know, mostly been doing software development if that gives you an interesting lens to look at these problems. JOËL: So, to get the full answer, you should probably ask me again in six months. STEPHANIE: That's fair. JOËL: Initial thoughts is that there's a shocking amount of overlap between some of these ideas, again, because I've done ETL-style projects a lot. You know, if you've got any kind of Rails app and you're integrating with a third-party API, you're often doing ETL at a very small level. To a certain extent, even if you're doing, let's say, some front-end code, and you're interacting with a back end, depending on how you want to deal with that transformation of getting data from your API, you might be doing something kind of like an ETL. Designing types in something like a TypeScript or an Elm and thinking in terms of the data that you have, the transforms that you're doing has a lot of similarities to what you would do in a data warehouse. I think a lot of the general ideas apply. I know I talked at the beginning of this year articles that were impactful for me. And one of those articles that was really impactful was Hillel Wayne's "Constructive Versus Predicative Data," which is all about structuring data and when you can enforce constraints via the data structure versus when you need to enforce it via code. Similarly, a lot of the ideas from the article "Parse, Don't Validate" by Alexis King. The articles focused on designing types. But it also, I think, applies to when you're thinking of schemas because schemas and types are, in a sense, isomorphic to each other. STEPHANIE: I like what you said there about as a software developer; you've probably done this at a much smaller scale. And, yeah, like you were saying, things that you had already learned about before or thought about before you're able to apply to this different set of problems or, like, different approach to programming. Is there anything that has been challenging for you? JOËL: Yes, and it's a weird one. Because we're working with enterprise systems, navigating the websites for these enterprise systems and the documentation for them is not a pleasant experience, trying to get a feel for how the system is made to work. It's just so different when you're used to tools and documentation written by the open-source community. Even third-party tutorials and things it's never, like, oh, here's a great article where you can scan and find the thing that you want. It's, hey, I'm a consultant guru on this thing. Sign up for my webinar, and you can have a 15-hour course on how to use this tool. And that's not what I want to do. I just want give me the five-paragraph blog post on how to do data imports, or how to set up a staging area for data, or something like that. STEPHANIE: Right. You're basically being asked to develop skills in using the enterprise software rather than more general skills for the problem or task; it sounds like. Because apparently, there are people making a business out of teaching other people how to use or navigate the software. JOËL: And I think that's fine. I love that people are making businesses of teaching these. But just the way things are structured, information is not generally as available for this large enterprise software as it is in the open-source world, and even when it is, it's just different patterns of access. So even you go to a particular technology's website, and it's all marketing copy. It's all sales funnel and not a lot of actually telling you really what the technology does. It's all, like, really vague, you know, business speak on, you know, empowering your team, and gathering insights, and all this stuff. So you really do a lot of drilling down. And what you need to find is the developer site. That's where you get the actual tech documentation. Depending on the tech, it's more or less good. But yeah, the official website of the technologies is just...it's not aimed at me as a developer. It's speaking to a different audience. STEPHANIE: That is interesting. I didn't realize that once you are, you know, working on a data warehouse, it is because you are consuming so many different external sources of data, and having to figure out how to work with each one is part of the process to get what you need. JOËL: So there's the external services but the data warehouse itself that we're using is an enterprise product. STEPHANIE: Got it. JOËL: So, just figuring out how this data warehouse works, it feels like it's a different culture, a different developer culture. STEPHANIE: That's cool. I'll definitely ask you again in a few months, and I look forward to hearing what you report back. So the other topic that I wanted to get into today is reviews, specifically self-reviews. To be honest, our review cycle is happening right now. And I have very much procrastinated [chuckles] on writing them until, you know, one or two days before. So I came into our conversation today, like, in that mind space of thinking about my growth, and my goals, and that kind of stuff. And it got me thinking that I don't hear a lot of people talk about reviews, and how to do them, how to write them for yourself, how to write them for others, how people approach them. Though I would guess that the procrastination part is pretty common, [chuckles] just based on what I'm hearing from other folks on our team too, and what they're up to for the next couple of days before they do. Joël, have you written your review yet? JOËL: So it's interesting because this review cycle has a few different components. You write a self-review. You write a review of your manager, and then you write a review of several of your peers who have nominated you to write a review. So I've done my own review. I've done my manager's review. I've not completed all of my peer reviews yet. STEPHANIE: That's pretty good. That's better than me. I've only done my own. [laughs] So, yeah, the deadline is coming up. And I'll probably get back to it right after this. I'm curious about your process, though, for writing a self-review. Do you come into it having thought about how you've been doing so far in the last six months or so? Or, when you sit down to write it, are you thinking about these things for the first time in a while? JOËL: Combination. So I think I do come in without necessarily having, like, planned for the review cycle. That being said, throughout the year, I try to build a fair amount of, like, personal self-reflection, professional self-reflection at various points throughout the year. So I'm not coming into the review cycle being like, oh, I have not thought about professional growth at all. What have I done this year? I think one thing I haven't done quite as well is when I'm doing these moments of self-reflection on my own throughout the year, writing down notes that I could then use to apply when the review cycle comes up. So I am having to rely on memory on, like, oh yeah, last month, when I kind of sat down and thought about areas that I want to improve in or areas that, like, what are my goals that I want to have? And I just commit that to memory. So, yeah, I think live in the moment; now that you've asked me this question, you've made me think that maybe I should be taking more regular notes about this. STEPHANIE: One thing I've been really liking about the software that we're using for reviews and other professional growth things is...it's called 15Five. And you can give your co-workers shout-outs using this tool. And as I was writing my review, I could actually open all of the kudos and shout-outs that I received from my peers and just remember some of the things that I worked on or a lot of the things that other people noticed. I tend to sometimes have a hard time remembering some of the smaller things that I've done that made an impact, but other people are usually better about pointing that out than I am. [chuckles] And that has been really helpful because it's, yeah, nice to see like, oh, like, you know, so and so really appreciated when I paired with them on, you know, debugging this thing. And maybe I can pull that into something that I'm writing about the kind of mentorship I've been doing in the last few months. JOËL: How do you feel about the aspect where you have to then give feedback on colleagues? STEPHANIE: I really value and enjoy this aspect because most of the time, I am just gassing my colleagues up [chuckles] and writing, you know, really encouraging things about all of the awesome work that they're doing. So, for me, it actually feels really good. And I was thinking a little bit about my approach to reviewing my peers and review culture in general. I have worked at companies where we have had a very, like, healthy and positive review culture. So it happens often enough that it's become normalized. It's not a really scary thing. And I also like to think about feedback in two types, where you have feedback that you want to give someone so that they can change behavior in a way that helps you work with them better, and then feedback you have for someone for their growth. And once I separated those two things, I realized that really, the former, if you're, you know, giving someone constructive feedback because you maybe would like them to be doing something different. That's not necessarily what you want to be writing in their annual review. Those things are usually better communicated in a more timely manner, like, right when you are noticing what you might want to be changed. And so then when you are doing reviews, like, you've hopefully already kind of gotten all of that stuff out of the way. And you can just focus on areas of growth for them, which is the fun part, I think, in reviewing peers because, yeah, you can give some suggestions to further support them in, like, where they want to go. JOËL: I like that distinction between just general growth, suggestions, and then interaction suggestions. And just to give an example, it sounds like interaction suggestions would be like, "Oh, when we pair, I would like it if you used this style of communication from, let's say, nonviolent communication. Here's a talk; go watch it." STEPHANIE: [laughs] Yeah, I did talk on this; go watch it. There used to be a framework for reviews that I've done before that I actually don't quite like. It's the Stop, Start, Continue framework where you answer questions about, okay, what should this person stopped doing? What should they continue doing? And what should they start doing? And the things that you would put in stop, I think, are probably what you would want to have communicated in a more timely manner, like, not necessarily it happening, you know, really divorced from whatever behavior you might be asking. And, in general, I think focusing on what you would like others to be doing instead is usually a better approach to handling that kind of feedback just because it avoids making someone feel bad about having done something wrong and, instead, kind of redirecting them into what you would like them to be doing. JOËL: So you're saying if you have something in the stop category, let's say stop interrupting me all the time when we're in meetings, you're saying this is something you prefer not to bring up at all or something that you prefer to bring up one on one and not in the context of review? STEPHANIE: Something to bring up one on one. Ideally, pretty soon after, that might have happened. It's a little more top of mind. And then you don't end up in that position of maybe misremembering or having the other person misremember and having to figure out, like, who was in the right or in the wrong in understanding how that interaction went. Especially if you're able to do it a little sooner after it happened, you can point out, like, hey, this happened. And instead of framing it as please stop interrupting me, you could say, "Could you please make some space for some folks who've been a little more quiet in the meetings to make sure that they've been able to share?" Still, I think once you've made more space to give that kind of constructive feedback when you are writing reviews, you can then, like, focus on the growth aspect and not the redirection of how others are doing their work. JOËL: That makes sense. So, what would be an example of the kind of feedback that you like to give to other people in the context of a review? STEPHANIE: Yeah, I think especially if I know what someone is wanting to focus on, right? If I'm working with someone, hopefully, we've kind of gotten to talk about what they like to work on, what they don't like to work on, what they are hoping to spend more time doing, or yeah, just their hopes and dreams for their professional [chuckles] development, being able to point out some things that they maybe haven't thought about trying it I really like to do. I was thinking about a time when I gave a co-worker some feedback as a mentee of theirs where they had been really awesome at providing information to me about things that I was unfamiliar with. But one thing that I was really hoping for was more tools to figure things out on my own. So instead of sending me a link to some documentation, maybe helping me figure out how to search for the documentation that I'm looking for. And that was something that I could share with them because I knew that they wanted to work on their mentorship skills and an opportunity, I think, for them to take it to a level where it's closer to coaching and not just providing information. JOËL: That makes a lot of sense. Maybe flipping it around, is there a point in time where you've received a review feedback that has been really valuable to you or really helped you hit the next level in your career? STEPHANIE: I really appreciate feedback that encourages me when I'm maybe a little bit too timid to go seek the things out myself. So there were times when I received some feedback about how great of a leader I could be before I thought I was ready to be a leader. And they pointed out the qualities of leadership that I had demonstrated that led them to believe that I would be ready for a role like that. And that was really helpful because I don't think that was even necessarily a short-term goal of mine. And it took someone else saying, "I think you're ready," that made me feel a lot more confident about opening that door. I guess this is all to say that I really love review season because of, you know, all of the support I get from my co-workers. And, yeah, just remembering that it's not just a journey I have to take all by myself, that the point of working with other people is for all of us to help each other grow. JOËL: I think something that you mentioned earlier really connected with me, the idea of trying to give feedback in the...even, like, feedback that's about changing or improving, phrasing it in a more positive way, or at least framing it in a more positive way. So here's an opportunity for growth rather than here's the thing you're doing wrong. Because that reminds me of two pieces of review that I got when I was a fairly junior developer that have stuck with me ever since. And one of them was really a catalyst for growth, and the other one kind of haunted me. So this first one I got, someone in a review just mentioned that they thought that I was just generally a slow developer, just not fast at writing code. Not a whole lot of context; just that's who I was. And, in a sense, it was almost like I'd been given this identity, like, oh, I am now Joël, the slow developer. And I didn't want that identity. So I'm kind of like, I want to refuse to accept it. But at the same time, there's always that self-doubt in the back. And now, anytime I'm on a project with someone else, I'm comparing, oh, am I shipping stories quite as fast as someone else? And if not, why? Is it because I'm a slow developer? Or if I'm having a rough day and I'm not getting the ticket done that I was hoping to get done by the end of the day, you know, you just get that voice in the back of your head that's like, oh, it's because you're a slow developer. Someone called that out last year, and they were right. So, in a sense, it kind of haunted me. On the flip side, I once got some feedback talking about an opportunity for growth. If I focused on working in more iterative, incremental chunks, it would help have a smoother workflow and probably help me work faster as well. And that was really kind of an exciting opportunity. It's also stuck with me for years but not in the sort of haunting sort of way or this, like, bring in self-doubt but more in terms of opportunity. Because now I'm always like, oh, can I break this down into even smaller chunks? Would that help me move faster? Would that help me be less blocked on other people? Would that be easier for our QA team? Would this be easier for review for my colleagues? Just a lot of different opportunities for benefits with working in smaller iterative chunks. And, for years, I've just been kind of honing that skill. And now, looking back over, you know, a decade of doing this, I think it's one of the best skills that I have. And so, in a sense, I feel like both of these people that left me that review, in a sense, they're trying to get me to maybe have a slightly higher velocity. But they're different approaches, radically different in terms of how it impacted me as a person. STEPHANIE: Yeah, I am really glad you brought that up. Because I definitely have also received, quote, unquote, "constructive feedback," but maybe wasn't phrased in the right way, that also haunted me. And it doesn't feel good. I think that that sucks. That person wasn't really able to frame it in a way that pushed you to progress in the positive way that you mentioned with learning to work incrementally. And in fact, I almost think that the difference in those two phrasings is encapsulated by a framework for giving feedback that's actionable, specific, and kind. So suggesting you to work incrementally is all of those things, especially if they know that you do want to increase your velocity. But you're being supported in doing it in a way that is positive and growth-oriented as opposed to, like, out of fear that other people think that you are a slow developer. And, you know, that's certainly a way that people are motivated. But I would say that that's not the way that we want to be motivated. [laughs] JOËL: I'm glad we're having this conversation because I think it just reinforces to me just the value of good communication skills for developers. And, you know, you can see that when developers have to write documentation, or even things like comments or commit messages. You see it when developers write blog posts. So it's really valuable to work on your communication skills in a lot of these technical areas. But reviews are a very particular area where it's easy to maybe have not the impact that you wanted because you communicated a core idea that's probably right, but just the way it was communicated was not going to have the impact that you're hoping for. And so getting good at communicating specifically in the area of reviews, which I assume most of us in the software industry are doing on a semi-regular basis, is probably a good tool to have in your professional tool belt. STEPHANIE: Absolutely. JOËL: We recently hit a big milestone at thoughtbot, where thoughtbot turned 20 years old in early June. And so, throughout June, we've been doing a lot of fun internal things and some external things to celebrate turning 20. And one of those is we're hosting a live AMA with a variety of thoughtbot devs. That's going to be on Friday, June 23rd, so a couple of days after this podcast goes live. So, to our listeners, if you're listening to this, in the first few days after it goes live, you get a chance to join in on the live AMA and ask your questions of our team as we celebrate 20 years. There's a blog post with all the details, and we'll link to that in the show notes. STEPHANIE: One other thing that I think we're doing that's really cool for our 20th anniversary is we published a short ebook with a curated collection of 20 hits from our blog, the thoughtbot blog, over the course of its history, some of the more popular and impactful blog posts that we've ever published. So I highly recommend checking that out. You know, the thoughtbot blog is such an awesome resource. And I discovered a few things that I hadn't read before on the blog from this ebook. So that will also be linked in the show notes. JOËL: I mentioned earlier how one of my opportunities for growth through review was getting better at working iteratively. And, a couple of years ago, I took a lot of the lessons that I'd learned over the years of getting better at working iteratively, and I put them in a blog post, and that blog post made it into that 20th Anniversary ebook. So we can probably link the blog post itself in the show notes. But also, if you're picking up that ebook, you'll get a chance to see that article on my lessons learned on how to work iteratively. STEPHANIE: Awesome. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Stephanie is joined by very special guest, fellow thoughtboter, Senior Developer, and marathon trainer Mina Slater. Mina and Stephanie had just been traveling together for two weeks, sponsored by WNB.rb for RubyKaigi in Matsumoto, Japan, and together, they recount their international adventure! RubyKaigi (https://rubykaigi.org/2023/) WNB.rb (https://www.wnb-rb.dev/) Understanding the Ruby Global VM Lock by observing it by Ivo Anjo (https://rubykaigi.org/2023/presentations/KnuX.html#day1) gvl-tracing (https://github.com/ivoanjo/gvl-tracing) Justin Searls' RubyKaigi 2023 live coverage (https://blog.testdouble.com/field-reports/ruby-kaigi/) Prioritizing Learning episode (https://www.bikeshed.fm/362) 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 and today. I'm joined by a very special guest, fellow thoughtboter Mina Slater. Mina, would you like to introduce yourself to our audience? MINA: Yeah. Hi, everyone. I am Mina. I am a Senior Developer on Mission Control, which is thoughtbot's DevOps and SRE team. STEPHANIE: So, Mina, what's new in your world? MINA: Well, I start marathon training this week. So I hope that this conversation goes well and lasts you for three months because you're probably not going to see or hear from me all summer. STEPHANIE: Yes. That sounds...it sounds hard, to be honest, marathon training in the summer. When I was doing a bit more running, I always thought I would wake up earlier than I did and, you know, beat the heat, and then I never would, and that really, like, was kind of rough. MINA: Yeah, actually, I was thinking about my plans for today. I didn't wake up early enough to run in the morning. And so I was calculating, like, okay, by midday, it's going to be too hot. So I'm going to have to wait until, like, 6:00 p.m. [laughs] STEPHANIE: Yeah, yeah. Or, if you're like me, there's a very real chance that you just skip it altogether. [laughter] MINA: Well, I have a deadline, so... [laughs] STEPHANIE: That's true. When is your marathon race? MINA: This is actually the first year I'm doing two in a calendar year. So I'm doing Berlin in September. And then, three weeks after that, I'm going to run one in Detroit. STEPHANIE: Nice. At least you'll be ready. You'll, like, have done it. I don't know; it kind of sounds maybe a bit more efficient that way. [laughs] MINA: Theoretically. But, you know, ask me in October. I'll let you know how it goes. STEPHANIE: That's true. You might have to come back on as a guest. [laughs] MINA: Just to talk about how it went. [laughs] STEPHANIE: Yeah, exactly. MINA: So that's what's new with me. What's new in your world, Steph? STEPHANIE: So, a while back on a previous Bike Shed episode, I talked about joining this client team and, in their daily team syncs, in addition to just sharing what we were up to and what we were working on, we would also answer the question what's something new to us. And that was a space for people to share things that they learned or even just, like, new things that they tried, like food, or activities, or whatnot. And I really enjoyed it as a way to get to know the team, especially when I was new to that client project. And recently, someone on the team ended up creating a random question generator. So now the question for the daily sync rotates. And I've been having a lot of fun with that. Some of the ones that I like are, what made you laugh recently? What's currently playing on your Spotify or YouTube? No cheating. MINA: [laughs] STEPHANIE: And then, yesterday, we had what's for dinner? As the question. And I really liked that one because it actually prompted me to [chuckles] think about what I was going to do for dinner as opposed to waiting till 5:00 p.m. and then stressing because I'm already hungry but don't have a plan [chuckles] for how I'm going to feed myself yet. So it ended up being nice because I, you know, kind of was inspired by what other people mentioned about their dinner plans and got my stuff together. MINA: That's shocking to me because we had just come off of two weeks of traveling together. And the one thing I learned about you is that you plan two meals ahead, but maybe that is travel stuff. STEPHANIE: I think that is extremely correct. Because when you're traveling, you're really excited about all the different things that you want to eat wherever you are. And so, yeah, we were definitely...at least I was planning for us, like, two or three meals [laughs] in advance. MINA: [laughs] STEPHANIE: But, when I'm at home, it is much harder to, I don't know, like, be motivated. And it just becomes, like, a daily chore. [laughs] So it's not as exciting. MINA: I think I'm the same way. I just had a whole bunch of family in town. And I was definitely planning dinner before we had breakfast because I'm like, oh, now I have to be responsible for all of these people. STEPHANIE: Yeah. I just mentioned the questions because I've been really having fun with them, and I feel a lot more connected to the team. Like, I just get to know them more as people and the things they're interested in, and what they do in their free time. So, yeah, highly recommend adding a fun question to your daily syncs. MINA: Yeah, we started doing that on Mission Control at our team sync meetings recently, too, where the first person...we actually have an order generator that somebody on the team wrote where it takes everyone's first and last name and scramble them and then randomizes the order. So you kind of have to figure out where in the queue you are and who's coming up next after you. But the first person that goes in the queue every day has to think of an icebreaker question. STEPHANIE: That's kind of a lot of pressure [laughs] for a daily meeting, especially if you're having to unscramble names and then also come up with the icebreaker question. I personally would be very stressed [laughs] by that. But I also can see that it's...I also think it's very fun, especially for a small team like yours. MINA: Yeah, yeah, just seven of us; we get to know really well what letters are in everyone's names. But I was first today, and I didn't have an icebreaker question ready. So I ended up just passing. So that's also an option. STEPHANIE: That's fair. Maybe I'll link you to our random question generator, so you can find some inspiration. [laughs] MINA: Yeah, it's a ChatGPT situation. STEPHANIE: So you mentioned that you and I had just been traveling together for two weeks. And that's because Mina and I were at RubyKaigi in Matsumoto, Japan, earlier this May. And that's the topic of today's episode: Our Experience at RubyKaigi. And the really cool thing that I wanted to mention was that this was all possible because Mina and I were sponsored by WNB.rb, which is a global community of women and non-binary people working in Ruby. And I've mentioned this group on the show before, but I wanted to plug it again because I think that this was something really special that we got to do. WNB runs a lot of initiatives, like, meetups and panels supporting people to speak at conferences and book clubs. And, you know, just many different programming events for supporting women and non-binary Rubyists in their career growth. And they are recently beginning a new initiative to sponsor folks to attend conferences. And Mina, you and I were the first people to get to try this out and go to an international conference. So that was really awesome. It was something that I don't think I would have done without the support from WNB. MINA: And you almost didn't do. I think there was a lot of convincing [chuckles] that went on at the beginning to kind of get you to, like, actually consider coming with me. STEPHANIE: It's true. It's true. I think you had DMed me, and you were, like, so, like, RubyKaigi, like, eyeball emoji. [laughs] I was, I think, hesitant because this was my first international conference. And so there was just a lot of, like, unknowns and uncertainty for me. And I think that's going to be part of what we talk about today. But is there anything that you want to say about WNB and how you felt about being offered this opportunity? MINA: Yeah. When Emily and Jemma, the founders of WNB, approached us with this opportunity and this offer, I think I was...taken aback is not really quite the right words but, like, surprised and honored, really, I think it's a better word. Like, I was very honored that they thought of us and kind of took the initiative to come to us with this offer. So I'm really grateful for this opportunity because going to RubyKaigi, I think it's always something that was on my radar. But I never thought that...well, not never. I thought that I had to go as a speaker, which would have been, like, a three to five-year goal. [laughs] But to be able to go as an attendee with the support of the group and also of thoughtbot was really nice. STEPHANIE: Yeah, absolutely. That investment in our professional development was really meaningful to me. So, like you, I'm very grateful. And if any of our listeners are interested in donating to WNB.rb and contributing to the community's ability to send folks to conferences, you can do so at wnb-rb.dev/donate. Or, if you work for a company that might be interested in sponsoring, you can reach out to them at organizers@wnb-rb.dev. MINA: I highly recommend doing that. STEPHANIE: So, one of the questions I wanted to ask you about in terms of your RubyKaigi experience was, like, how it lined up with your expectations and if it was different or similar to what you were expecting. MINA: Yeah, I have always heard that when people talk about RubyKaigi as a conference and about its contents, the word that everyone uses to describe it is technical. I have already had sort of a little bit of that expectation going in. But I think my interpretation of the word technical didn't really line up with how actually technical it was. And so that was one thing that was different than what I had expected. STEPHANIE: Could you elaborate on what was surprising about the way that it was technical? MINA: Yeah. I think that when I hear technical talks and having been to some Ruby and Rails confs here in the States, when I hear about technical talks, it's a lot more content about people using the technology, how they use Ruby to do certain things, or how they use Rails to achieve certain goals in their day-to-day work or side projects. But it seems at RubyKaigi; it is a lot more about the language itself, how Ruby does certain things, or how interpreters implement Ruby, the language itself. So I think it's much more lower-level than what I was expecting. STEPHANIE: Yeah, I agree. I think you and I have gone to many of Ruby Central conferences in the U.S., like RubyConf and RailsConf. So that was kind of my comparison as well is that was, you know, the experience that I was more familiar with. And then, going into this conference, I was very surprised that the themes of the talks were, like you said, very focused on the language itself, especially performance, tooling, the history and future of Ruby, which I thought was pretty neat. Ruby turns 30, I think, this year. And one thing that I noticed a lot was folks talking about using Ruby to reflect on itself and the possibilities of utilizing those capabilities to improve our experience as developers using the language. MINA: Yeah. I think one of the things I was really fascinated by is...you had mentioned the performance. There were several talks about collecting how Ruby performs at certain levels. And I thought that that was quite interesting and things I had never thought about before, and I'm hoping to think about in the future. [laughs] STEPHANIE: Yeah. One talk that I went to was Understanding the Ruby Global VM Lock by Ivo Anjo. And that was something that, you know, I had an awareness of that Ruby has this GVL and certain...I had, like, a very hand-wavy understanding about how, like, concurrency worked with Ruby because it hasn't been something that I've really needed to know too deeply in my day-to-day work. Like, I feel a little bit grateful not to have run into an issue where I had to, you know, dive deep into it because it was causing problems. [laughs] But attending that talk was really cool because I liked that the speaker did give, like, an overview for folks who might be less familiar but then was able to get really deep in terms of, like, what he was doing workwise with improving his performance by being able to observe how the lock was being used in different threads and, like, where it might be able to be improved. And he shared some of his open-source projects that I'll link in the show notes. But, yeah, that was just something that I was vaguely aware of and haven't yet, like, needed to know a lot about, but, you know, got to understand more by going to this conference. And I don't think I would have gotten that content otherwise. MINA: Yeah, I agree. The talk that you are referencing is one of my favorite as well. I think, like you, kind of this vague idea of there's things going on under the hood in Ruby is always there, but to get a peek behind the curtain a little bit was very enlightening. I wrote down one of the things that he said about how highly optimized Ruby code can still be impacted and be slow if you don't optimize GVL. And he also shared, I think, some strategies for profiling that layer in your product, if that is something you need, which I thought was really cool. STEPHANIE: Yeah. I think I had mentioned performance was a really big theme. But I didn't realize how many levers there were to pull in terms of the way Ruby is implemented or the way that we are able to use Ruby that can improve performance. And it's really cool to see so many people being experts at all of those different components or aspects of making Ruby fast. [laughs] MINA: Yeah. I think that part of the work that we do on Mission Control is monitoring performance and latency for our clients. And while I don't expect having to utilize some of the tools that I learned at RubyKaigi, I expect being aware of these things helping, I think, in the long run. STEPHANIE: Yeah, absolutely. Joël and I have talked on the show about this idea of, like, push versus pull learning. So push, being you consume content that may not be relevant to you right now but maybe will be in the future. And you can remember, like, oh, I watched a talk on this, or I read something about this, and then you can go refer back to it. As opposed to pull being, like, I have this thing that I don't understand, but I need to know right now, so I'm going to seek out resources about it. And I think we kind of landed on that both are important. But at Kaigi, especially, this was very much more push for me where there's a lot of things that I now have an awareness of. But it's a little different, I think, from my experience at Ruby Central conferences where I will look at the schedule, and I will see talks that I'm like, oh, like, that sounds like it will be really relevant to something I'm working through on my client project or, like, some kind of challenging consulting situation. And so the other thing that I noticed that was different was that a lot of the U.S. conferences are more, I think like business and team challenges-focused. So the talks kind of incorporate both a technical and socio-cultural aspect of the problems that they were solving. And I usually really like that because I find them very relatable to my day-to-day work. And that was something that was less common at Kaigi. MINA: Also, that I've never been to a conference that is more on the academic side of things. So I don't know if maybe that is more aligned with what Kaigi feels like. STEPHANIE: Yeah, that's true. I think there were a lot of talks from Ruby Committers who were just sharing, like, what they've been working on, like, what they've been thinking about in terms of future features for Ruby. And it was very much at the end of those talks, like, I'm open to feedback. Like, look out for this coming soon, or, like, help contribute to this effort. And so it was interesting because it was less, like, here are some lessons learned or, like, here are some takeaways, or, like, here's how we did this. And more like, hey, I'm, you know, in the middle of figuring this out, and I'm sharing with you where I'm at right now. But I guess that's kind of the beauty of the open-source community is that you can put out a call for help and contributions. MINA: Yeah, I think they call that peer review in the academic circles. STEPHANIE: [laughs] That's fair. MINA: [laughs] STEPHANIE: Was there anything else that you really enjoyed about the conference? MINA: I think that one of my favorite parts, and we've talked about this a little bit before, is after hours on the second day, we were able to connect with Emori House and have dinner with their members. Emori House is a group that supports female Kaigi attendees specifically. I think it's that they, as a group, rent out an establishment or a house or something, and they all stay together kind of to look out for each other as they attend this very, I think, male-dominated conference. STEPHANIE: Yeah. I loved that dinner with folks from Emori House too. I think the really cool thing to me is that it's just community and action, you know, like, someone wanted to go to this conference and make it easier for other women to go to this conference and decided to get lodging together and do that work of community building. And that social aspect of conferences we hadn't really talked about yet, but it's something that I really enjoy. And it's, like, one of the main reasons that I go to conferences besides learning. MINA: Yeah, I agree. At the Ruby Central conferences, one of my favorite parts is always the hallway track, where you randomly meet other attendees or connect with attendees that you already knew. And like I mentioned, this dinner with Emori House happened on the second night. And I think by midday second day; I was missing that a little bit. The setup for RubyKaigi, I noticed, does not make meeting people and organizing social events as easy as I had been used to, and part of that, I'm sure, is the language barrier. But some places where I had met a lot of the people that I call conference friends for Ruby Central conferences had been at the lunch table. And Kaigi sets up in a way where they send you out with food vouchers for local restaurants, which I thought was really cool. But it doesn't make meeting people and organizing groups to go out together with people you don't already know a little more difficult. So meeting Emori House on the second night was kind of exactly what I had been missing at the moment. STEPHANIE: Yeah, agreed. I also really thrive off of more smaller group interactions like organically, you know, bumping into people on the hallway track, ideally. I also noticed that, at Kaigi, a lot of the sponsors end up hosting parties and meetups after the conference in the evenings. And so that was a very interesting social difference, I think, where the sponsors had a lot more engagement in that sense. You and I didn't end up going to any of those drink-ups, are what they're called. But I think, similarly, if I were alone, I would be a little intimidated to go by myself. And it's kind of one of those things where it's like, oh, if I know someone, then we can go together. But, yeah, I certainly was also missing a bit of a more organic interaction with others. Though, I did meet a few Rubyists from just other places in East Asia, like Taiwan and China. And it was really cool to be in a place where people are thinking about Ruby differently than in the U.S. I noticed in Japan; there's a lot more energy and enthusiasm about it. And, yeah, just folks who are really passionate about making Ruby a long-lasting language, something that, you know, people will continue to want to work with. And I thought that was very uplifting because it's kind of different from what the current industry in the U.S. is looking like in terms of programming languages for the jobs available. MINA: It's really energizing, I think, to hear people be so enthusiastic about Ruby, especially, like you said, when people ask me what I do here, I say, "Developer," and they say, "Oh, what language do you work in?" I always have to be kind of like, "Have you heard of Ruby?" [laughs] And I think it helps that Ruby originated in Japan. They probably feel a little bit, like, not necessarily protective of it, but, like, this is our own, and we have to embrace it and make sure that it is future-facing, and going places, and it doesn't get stale. STEPHANIE: Right. And I think that's really cool, especially to, you know, be around and, like, have conversations about, like you said, it's very energizing. MINA: Yeah, like you mentioned, we did meet several other Rubyists from, like, East Asian countries, which doesn't necessarily always happen when you attend U.S.-based or even European-based conferences. I think that it is just not as...they have to travel from way farther away. So I think it's really cool to hear about RubyConf Taiwan coming up from one of the Rubyists from Taiwan, which is awesome. And it makes me kind of want to go. [laughs] STEPHANIE: Yeah, I didn't know that that existed either. And just realizing that there are Rubyists all over the world who want to share the love of the language is really cool. And I am definitely going to keep a lookout for other opportunities. Now that I've checked off my first international conference, you know, I have a lot more confidence about [laughs] doing it again in the future, which actually kind of leads me to my next question is, do you have any advice for someone who wants to go to Kaigi or wants to go to an international conference? MINA: Yeah, I think I have both. For international conferences in general, I thought that getting a buddy to go with you is really nice. Steph and I were able to...like, you and I were able to kind of support each other in different ways because I think we're both stressed [laughs] about international travel in different ways. So where you are stressed, I'm able to support, and where I'm stressed, you're able to support. So it was really nice and well-rounded experience because of that. And for RubyKaigi specifically, I would recommend checking out some of the previous year's talks before you actually get there and take a look at the schedule when it comes out. Because, like we said, the idea of, I think, technical when people use that word to describe the content at RubyKaigi is different than what most people would expect. And kind of having an idea of what you're getting into by looking at previous videos, I think, will be really helpful and get you in the right mindset to absorb some of the information and knowledge. STEPHANIE: Yeah, absolutely. I was just thinking about...I saw in Ruby Weekly this week Justin Searls had posted a very thorough live blogging of his experience at Kaigi that was much more in the weeds of, like, all of the content of the talks. And also had tips for how to brew coffee at a convenience store in Japan too. So I recommend checking that out if folks are curious about...especially this year before the videos of the talks are out. I think one thing that I would do differently next time if I were to attend Kaigi or attend a conference that supports multiple languages...so there were talks in Japanese and English, and the ones in Japanese were live interpreted. And you and I had attended, like, one or two, but it ended up being a little tough to follow because the slides were a little bit out of sync with the interpretation. I definitely would want to try again and invest a little more into attending talks in Japanese because I do think the content is still even different from what we might be seeing in English. And now that I know that it takes a lot of mental energy, just kind of perhaps loading up on those talks in the morning while I'm still, you know -- MINA: [laughs] STEPHANIE: Fresh-faced and coffee-driven. [laughs] Rather than saving it for the afternoon when it might be a little harder to really focus. MINA: I think my mental energy has a very specific sweet spot because definitely, like, late in the afternoon would not be good for that. But also, like, very early in the morning would also not be very good for that because my coffee hasn't kicked in yet. STEPHANIE: That's very real as well. MINA: Do you think that there is anything that the conference could have done to have made your experience a little tiny bit better? Is there any support that you could have gotten from someone else, be it the conference, or WNB, or thoughtbot, or other people that you had gone with that could have enhanced this experience? STEPHANIE: Hmm, that's an interesting question. I'm not really sure because I was experiencing so many new things -- MINA: [laughs] STEPHANIE: That that was kind of, like, what was top of mind for me was just getting around even just, like, looking at all the little sponsor booths because that was, like, novel for me to see, like, different companies that I've never heard of before that I think when I asked you about expectations earlier, like, I actually came in with not a lot of expectations because I really was just open to whatever it was going to be. And now that I've experienced it once, I think that I have a little more of an idea of what works for me, what I like, what I don't like. And so I think it really comes down to it being quite a personal experience and how you like to attend conferences and so -- MINA: For sure. STEPHANIE: At the end of the day, yeah, like, definitely recommend just going if that opportunity is available to you and determining for yourself how you want that experience to be. MINA: Certainly. I think just by being there you learn a lot about what you like in conferences and how we like to attend conferences. On a personal level, I'm also an organizer with Ruby Central with their scholarship committee. And that's somewhere where we take new Rubyists or first-time conference attendees and kind of lower the barrier for them to attend these conferences. And the important part I wanted to get to is setting them up with a mentor, somebody who has attended one of these conferences before that can kind of help them set goals and navigate. And I thought that someone like that would...at RubyKaigi, being both our first times, might be useful. STEPHANIE: Yeah, absolutely. I think that's totally fair. One thing I do really like about the Ruby Central conferences is the social support. And I think you had mentioned that maybe that was the piece that was a little bit missing for you at this conference. MINA: Yeah. I know that someone had asked early on, I think, like, the night before the conference officially kicked off, whether there is a Slack or Discord space for all conference attendees so that people can organize outings or meals. And that is definitely something that at least the Ruby Central conferences have, and I imagine other conferences do too, that was missing at Kaigi as well. STEPHANIE: I'm wondering if you would go to Kaigi again and maybe be that mentor for someone else. MINA: I think so. I think I had different feelings about it when we were just leaving the conference, kind of feeling like some of these things that I'm learning here or that I'm being made aware of rather at RubyKaigi will come up important in the future, but maybe not right away. So then I was kind of walking away with a sense of, like, oh, maybe this is a conference that is important, but I might deprioritize if other opportunities come up. But then I started to kind of, like, jot down some reflections and retroing with myself on this experience. And I thought what you mentioned about this being the sort of, like, the push learning opportunity is really nice because I went in there not knowing what I don't know. And I think I came out of it at least being a little bit aware of lots of things that I don't know. STEPHANIE: Yeah, yeah. Maybe, like, what I've come away with this conversation is that there is value in conferences being different from each other, like having more options. And, you know, one conference can't really be everything for everyone. And so, for you and I to have had such a very different experience at this particular conference than we normally do, that has value. It also can be something that you end up deciding, like, you're not into, and then you know. So, yeah, I guess that is kind of what I wanted to say about this very new experience. MINA: Yeah, having new experiences, I think, is the important part. It's the same idea as you want to get a diverse group of people in the room together, and you come out with better ideas or better products or whatever because you have other points of view. And I think that attending conferences, even if not around the world, that are different from each other either in academia or just kind of, like, branching out of Ruby Central conferences, too, is a really valuable experience. Maybe conferences in other languages or language-agnostic conferences. STEPHANIE: Yeah, well said. On that note, shall we wrap up? MINA: Let's do it. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

If you're in the market for bicycle shorts, Joël's got you. Stephanie just returned from RubyKaigi in Japan and shares details of her trip. Recently at thoughtbot, there have been conversations around an interesting data modeling exercise. Joël and Stephanie discuss the following: Value Objects vs. Hashes Doing Math on Compound Numbers Monoids and Folding Naming Concepts in Code This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Ruby Kaigi (https://rubykaigi.org/2023/) Google Translate Lens (https://lens.google/) Video on city parks (https://www.youtube.com/watch?v=qnyikrFlGdU) Enumerable#tally (https://ruby-doc.org/3.2.2/Enumerable.html#method-i-tally) Hash#merge (https://ruby-doc.org/3.2.2/Hash.html#method-i-merge) Monoids (https://blog.ploeh.dk/2017/10/06/monoids/) Enumerable#all? (https://ruby-doc.org/3.2.2/Enumerable.html#method-i-all-3F) Value of specialized vocabulary (https://www.bikeshed.fm/356) Gist with Joël's code solution (https://gist.github.com/JoelQ/3056a0a6e8b5488faa5caeef630cd702) 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: I've made an unusual purchase this week. I went out and bought a pair of bicycle shorts. And, for those who are not aware, these are special shorts that have padding built into them. Typically, they're, like, skin-tight, but I got, I guess, what are called mountain biking shorts. So, they kind of look more like the cut of a normal short. But they've got this, like, built-in padding for biking. STEPHANIE: So. Just to confirm, you did get these shorts for biking purposes, right? JOËL: Yes. I purchased these shorts for biking purposes. STEPHANIE: Okay. [laughs] JOËL: And I got these because I was talking to a friend about this and mentioning that this was, like, probably the most ambitious cycling thing I've ever done in my life. And they recommended if you have not done bike shorts, you really should get them. They make a big difference. STEPHANIE: Wow. Okay, I have two thoughts here. First of all, you prefaced this saying that this was an unusual purchase. So I thought maybe that you bought these bike shorts for some other purpose. [laughs] But I am excited to talk about this because I've also been curious about trying bike shorts. I bike a lot in Chicago in the summer, and I've been doing, like, longer rides on the Lakefront trail. And one of my goals, actually, this summer is to do a bikepacking trip. But I have not been super comfortable on longer rides. And I was just thinking that this might be something really helpful to make them a little more enjoyable. JOËL: So, is the kind of biking that you're doing closer to what might be considered commuting? STEPHANIE: Yeah, mostly commuting. But also, just, like, going on long rides on the weekends, in addition to this, hopefully, forthcoming bikepacking trip up to a state park. So not too long, maybe, like, 60 miles, but definitely long enough to start getting a little uncomfy on your seat. JOËL: Yeah, is 60 miles, like, in one day? STEPHANIE: Yeah, exactly. JOËL: That's a lot. Yeah, the friend who recommended biking shorts to me told me that pretty much anything over maybe 10 miles is worth getting shorts. STEPHANIE: Wow, okay. I clearly have been suffering [laughs] for way too long, then. Tell me more about your cycling trip. JOËL: So this is a bikes plus beer trip. Basically, I plotted a bunch of breweries in Belgium on a map and constructed an itinerary that could hit a bunch of them while keeping fairly short rides between towns. And the goal is to do maybe 30-35 miles in a day. And so I'll be going probably, like, cycling in the morning, and then exploring and drinking in the afternoon and evening. STEPHANIE: That sounds amazing. That's really cool to do a little bit of a tour of the area and then also traveling by bike. JOËL: Yeah, I'm excited because other modes of transport really just give you the origin and the destination, whereas cycling, you kind of get all of the in-between places. You get a much better feel for the area that you're in. And you can make all these unexpected stops if you want. You can make detours. So I feel like you get the sort of being in the moment, being in the place effect that you would have as a pedestrian but with a much longer reign. STEPHANIE: Yeah, absolutely. That's exactly what I was going to say. I love cycling. And there's something really special about being able to be present in your surroundings and seeing people on the street or a cool building as you're going. But also going at a speed where it feels very fun and very freeing to just be cycling through a town and making stops when you want to, and traveling greater distances than you could be able to on foot. JOËL: So I just received these bike shorts yesterday in the mail. So today, at the end of the day, I'm going out for a bike ride, and I'm going to see if they perform as advertised. STEPHANIE: That's exciting. Keep us posted [laughs] on if you end up liking them or not. JOËL: Yeah, yeah. The next episode or two, I'll have to report bike shorts; yay or nay? STEPHANIE: Yeah, The Bike Shed will now become bike gear reviews. JOËL: The name will actually line up, then with what the people googling, it might think it actually is. Stephanie, what's new in your world? STEPHANIE: Speaking of vacation, I just got back from a two-and-a-half-week trip myself. I mentioned on the podcast a couple of episodes ago, I think, that I was traveling to Japan for RubyKaigi, an international Ruby Conference over in Japan. And then I spent another week in Taiwan, just on my own time. So, yeah, I had a really big, long trip, and it was really great. It was my first time going abroad in a really long time. It was my first time being somewhere where I didn't speak the language. So, in Japan...I don't speak any Japanese. And it was both challenging and also, like, not too bad. I found my way around through a lot of gesturing and smiling, and nodding. [laughs] And, hopefully, people were able to understand what I was trying to communicate. Also, pointing at menus, I highly recommend going to places that have pictures of the food, and then you can just point when you want to order. [laughs] JOËL: So, did you find that English was not particularly useful then in Japan as a tourist? STEPHANIE: Yeah, I would say so. The next thing was that most signs were translated. So we ended up taking public transportation a lot. And that was quite easy to navigate, especially since I have kind of navigated subways in other cities before, and reading the signs is no problem. But when you're trying to communicate with locals, that was a little harder. JOËL: Did you use any, like, apps on your phone or anything like that to help navigate kind of the different language? STEPHANIE: Yeah, the Google Translate Lens app. I can't remember exactly what it is. But this was my first time really using it. And I was really impressed by how it was able to translate things that you're using your camera to take pictures of, or just, like, having your camera view. I did feel a little silly, like, holding my phone up to everything and trying [laughs]...so I could understand what I was reading. But for menus that did not have pictures, that was my backup strategy. [laughs] JOËL: Did you ever have to have your phone translate something and then just show your phone to someone else? STEPHANIE: No, I didn't have to go that far. Though I do think that it has a feature where you can have someone speak into the phone, and it will translate that into your native language. And then you respond by speaking into it and then playing the sound for them, which, you know, I bet really works in a pinch. But I think that required a little more investment into the interaction [laughs] with the other person than I was ready for. Like I said, the gesturing served me quite well. JOËL: I got the experience of being on the other side of that a while back. So, here in Boston, I was just walking down the street, and someone stopped me and just holds up their phone. And they've typed something in Chinese on there. And they hit a button, and it comes in English. STEPHANIE: [laughs] JOËL: And they're asking for directions. And I think I typed a sentence back on their phone in English, and then they hit the translate button and got it back in Chinese. We went back and forth a few times. And eventually, I think he got what he wanted, and we went our separate ways. And I was kind of amazed that this whole interaction happened. STEPHANIE: Yeah, that's really cool. JOËL: Yeah, kudos to that person for having the courage to stop someone on the street when you don't speak their language. STEPHANIE: Yeah, absolutely. I think even when I was struggling to communicate with someone because of the language barrier, I could tell from their gesturing in return that we were, like, willing to help each other out. And that, like, there was still an ability to find some kind of connection, even though, you know, we didn't completely understand each other. And that was definitely one thing that I really enjoyed was being in a place with, you know, people different from me and having that exposure. It's been a really long time since I've got to experience that, and that was really valuable. JOËL: So, other than the conference, what would you say are some highlights of the trip for you, maybe one from Japan and one from Taiwan? STEPHANIE: So one of my favorite things about being in Tokyo was all the green space that was around. I ended up walking a lot just to explore the neighborhoods. And I always just stumbled across a local park or even a shrine that had really great nature around it, a lot of big trees. You know, some, like, water features, maybe like a pond, and a lot of really fun plants that I got to learn about. And, yeah, that was really nice, especially in such a dense urban area, like, coming across green space to just sit for a little while. And it was such a nice relief from the density and busyness of a big city. That was just one thing that I was really impressed by being in Japan. JOËL: That's really cool. I think that really speaks to the quality of their urban planning. I know that the stereotype of Tokyo that I have in my mind is that it's, like, you know, ultra-modern, ultra-urban, you know, it's the largest city in the world. So the idea that they've taken the time to set up all these little parks everywhere is really endearing. Particularly, I think the idea of smaller parks at the neighborhood level where you don't need, you know, something massive like, let's say, New York's Central Park, which is, you know, really cool. But having just a little green space in your neighborhood where you can, like, stop by, I think it's a wonderful upgrade to local people's quality of life. I was recently listening to a video on YouTube from a city planning channel talking about just all the thinking that goes behind city parks, and having them at different scales, and how that impacts the residents of different areas. So it's really cool to hear that Tokyo has done a great job with that. STEPHANIE: Yeah, absolutely. I think part of the joy of just stumbling upon it was that you know, even when I wasn't seeking it out, it would just come along during my walks. And, yeah, it really was very refreshing. JOËL: What about Taiwan? STEPHANIE: So, in Taiwan, what I really enjoyed about it it's a bit of a smaller island. And so you can actually get to a lot of places within a few days. And a lot of folks take day trips out to the coast from Taipei. And I was able to do a two-day trip to another county that had some hot springs, and I got to enjoy an outdoor hot springs in the rain. And that was really nice because it was, like, surrounded by trees. And it happened to be raining that morning, but, you know, we were all kind of already getting wet, so it didn't really matter. And it was just, like, this really serene and gorgeous experience being able to enjoy that. And I think that was another place where I was in a very urban area, and then being able to escape a little bit was really nice. JOËL: That sounds like a magical moment. Have you visited hot springs before, or was this your first time going to a hot spring? STEPHANIE: I have been to a few in the U.S. before. I like to take road trips to national parks. And there are some really great hot springs in the U.S. as well. And so this was kind of something that I really wanted to do somewhere else just to experience it elsewhere. And, yeah, I'm really glad to have checked that off my bucket list. JOËL: That's really cool. I've never been to a hot spring, and it sounds like a fun thing to do. So it's on my kind of greater bucket list. It's maybe not a top-five thing to do, but definitely, something I want to do one day. STEPHANIE: Cool. Love it. That was vacation talk from Joël and Stephanie. [laughs] MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: So recently at thoughtbot, we've been having conversations around this really interesting data modeling exercise, where let's say this is a company, and you want to purchase T-shirts for everyone at the company. You have already some T-shirts on hand because you've done this kind of thing before in a couple of different warehouses. And you need to know how many new T-shirts you need to order in order to have enough for everyone. So as long as you keep things simple, the math is pretty easy because you sum the number of people at your company, and then you sum the number of shirts across all of your warehouses, and that gives you the T-shirts that you need, the T-shirts that you have. You get the difference between those two numbers, and that tells you how many new T-shirts you need to order. Where things get more complicated is once you start introducing T-shirt sizes, and that's where the fun data modeling comes in. If everyone at your company has a T-shirt size that they want and then at your warehouses, you store...the object that represents a warehouse stores a hash of sizes and how many of each size you have. Now, how do you do all this, like, summing across things? And it's not really just a single number that you want. Now you need to know how many small, mediums, and larges. And, sometimes, you've got a hash. Sometimes you've got just symbols on a user, and you've got a sum across hashes. Maybe do some differences across hashes. And it gets kind of tricky to work with. So that's sort of the problem as it's initially presented. And we've been having a really interesting conversation around different ways to try to solve it in a way that's really kind of clean and nice. STEPHANIE: Yeah, that's interesting because what you described sounds like the first iteration of solving the problem is, oh, the warehouse stores this information as a hash. So maybe I will create a new hash for the counts of T-shirt sizes that I need and then do the comparison on those two hashes. It sounds like maybe there was some unwieldiness or maybe even some duplicated code there. Is that what you think you all were trying to solve by modeling this differently? JOËL: I think we kind of quickly hit some limitations with hashes. One thing that is fun before we start trying to combine a bunch of hashes is that some of the data exists as a hash on the warehouses. But to get the T-shirts that we need, all we have are an array of users and a size on all of them. And we can use this fun method from Enumerable called Tally to give us a kind of Tally hash that is just a mapping of size, two counts of that size in the array. And so that's a really fun method. You don't get to bring it out that often in Ruby. And it's nice because that hash format happens to match the same format as the hashes stored on the warehouse objects. STEPHANIE: Right. So now you're comparing apples to apples. But it sounds like maybe this hash representation does hold some kind of significance. JOËL: Yeah. I guess, for me, I tend to see anytime you're doing fancier operations on a hash more than just reading in and out; it probably wants to be some kind of value object. And, in this case, we kind of want to do math on hashes. I think the equation is kind of still the same thing. We're trying to get the difference between the two, between the want versus have, but you can't just subtract one hash from another directly. There's some things that you can do with the hash merge method that allows you to pass a custom block and do some things there. But we're going to have to do this sort of repeatedly. And now we're kind of leaking some of that knowledge a little bit. So it feels like something where you might want to actually name this concept and make it an object of its own that can then have its own kinds of domain operations as methods on it. STEPHANIE: Yeah, I like that a lot. Because even just as I was thinking about it when you are storing data like that in just a hash, what do you call it? Like, what do you name it? I think I've seen things like that named, like, T-shirt data, or, like, warehouse data, or warehouse T-shirt counts, or T-shirt counts. You know, that is when it starts to diverge, and you end up maybe seeing the same, like, data represented, but it being named different things in different parts of the code. And I, in experience, have found that very painful. JOËL: Yeah, because I guess you could have, like, T-shirts on hand from your warehouse; that's one hash. But the hash generated from the users might get called something like user preferences. And if you're reading through that code and you see a hash, and you're like, okay, do these two hashes that I'm looking at, maybe in a test, just kind of coincidentally have the same keys? Or are these kind of fundamentally the same thing? Or is the idea of, like, T-shirts on hand like a stock different from, like, a preference? And do they represent different things that just happen to be similar in this particular scenario? STEPHANIE: Right. And especially if then there are methods where you're passing that data structure that really represents the same thing. But you're passing it as arguments, and then, suddenly, one variable name, user preferences, or user T-shirt preferences becomes, you know, T-shirt count. That has been really confusing for me before. JOËL: One thing that does get, I think, clunky very quickly is that you have all of these warehouse objects that have that hash of, like, stock on hand on them. And what you really want is a kind of aggregate object that tells you not what's the stock on hand for one warehouse but across all warehouses. So you've got to go through, I guess, that array of warehouses and somehow kind of aggregate all of those hashes together. And because they're already tallies, you can't just do Enumerable Tally on it anymore. You've got to find some way to combine them together, and that gets tricky really quickly. STEPHANIE: Right. I can see they're starting to be, like, nested loops, especially if you're just working with primitives. JOËL: I think some initial implementations that we saw ended up doing either, like, some kind of reduce block or eachwithobject, or something like that, which are, I think, fine solutions here. But what lives inside of those blocks is what gets complicated. And I don't know about you, but I feel like if I'm reading through some code and then all of a sudden I see a reduce block, and it's, like, ten lines of logic with maybe some, like, nested things, like, maybe some nested loops or some conditions inside of it, that's kind of intimidating. Reduce is not a super easy method to wrap your head around, especially when the block has got a lot of logic. STEPHANIE: Yeah, that's a really good point. It definitely gives me pause. And I have to, like, you know, commit to reading the method in its entirety to fully understand [laughs] what's going on. JOËL: Sometimes, like, really pause and, like, annotate with comments and all this stuff. STEPHANIE: So, what did you end up thinking about in terms of solving that problem of aggregating the sums of all the different T-shirt sizes for each warehouse? JOËL: So I think, for me, oftentimes, it's easier to make the problem a little bit smaller, solve that smaller problem, and then try to kind of scale up back up again and particularly when you're dealing with something like reducing or aggregating a large collection. Like, forget about dealing with a collection. Just how could I combine two items of this type? So if I had two of these hashes. And forget about fitting it for an array. But if I have two of these hashes, how could I combine them together? And you could do this with hash merge. I wanted to do things a little bit more encapsulated. And because I also knew that we're building some more logic around these, I actually wrote a custom object. I called it a tally, maybe inspired by that Enumerable method, and implemented an operator plus on this tally object. So a tally object can plus another tally object. And the response from that is you get a third tally object that's gone through all of the keys and summed them together. So it's kind of an aggregate sum. STEPHANIE: This is a cool example of a method that's a verb also representing a noun to name the return value, right? So the Tally method on Enumerable returns a hash, which we have been talking about for a while as, like, a data structure that's, you know, perfectly fine, but maybe we can leverage turning it into like you said, a value object to give it more meaning or to make it easier to work with. And it seems like the naming part just kind of fell into your lap. JOËL: Yeah, tally is interesting in that it is both a noun and a verb in English. I'm not sure what the grammatical term for that kind of word is. STEPHANIE: So, once you extracted this new class out, what insights or observations did you have about this problem? JOËL: What becomes really cool about this is that once you have a way of combining two objects together, reduce is a way to just kind of scale that up to an arbitrary number. And so, just like you can sum an array of numbers by reducing plus over the array. Because I have plus on my tally object, I can reduce plus operator over an array of tally objects. And they all just kind of sum together in a single tally that's the combination of all of them. So this is really cool. What used to be an intimidating reduce block, the intimidating logic gets moved into a plus method, which I think is much more approachable. Because I can go in the context of an object and say, okay, I've got this tally object, and I'm trying to add it to another tally object. And we're just going one key at a time, adding them together. Simple enough. And then in the place where we're reducing, all we're saying is list of tallies reduce plus. And I know that pattern already because I do it with integers to sum them together. And so now I've just got this really simple one-line in the scary part. And the actual complex logic is much more approachable. STEPHANIE: That is very cool. I found it really interesting that this came about because we were trying to do math on these two hashes. So it seems like, you know, a tally because it represents a score or, like, a number. Like, we were able to implement those plus operators and get to a simple solution because we're working with numbers. JOËL: Yeah, I think it might be fair to describe it as maybe a compound number is the term that I use. I don't know if that's mathematically correct. Oftentimes, when you're dealing with things that represent a number or something that's represented numerically but that might have more than one number involved in it. But you still want to do math with this kind of compound, multi-number value anyway. And one example that you might have is, let's say, a point in 2D space. You have an X coordinate and a Y coordinate. And you can do math on points. In fact, there's a whole field of math to deal with that kind of thing. That's an important thing that you have to do. You might want to be able to add or subtract points. You might want to do certain types of multiplication on them. And so just because something has more than one number associated to it doesn't mean that it can't be used for math. In fact, oftentimes, that's where the fancier math does come into play. But when we treat them as primitives, and we just have, let's say, our XY pair was a hash, or, like, a two-element array, then we lose the ability to do math nicely. If we create, let's say, a point class that has an X and Y, and then we define plus, we define minus, we define scalar and vector multiplication, things like that, now we can do all those operations. And we can treat it like math, even though it's not just a simple integer anymore. STEPHANIE: Yeah, I like that a lot because we do end up working with data, you know, maybe even from our database. But then, inevitably, we want to, like, learn something about it. And so I was thinking about how frequently I use GROUP BY in MySQL queries and how, oftentimes, I care about counts, or, like, number of records. And perhaps this is why we see, like, the hash primitive used so frequently in codebases that then become pretty complicated once we're trying to, like I mentioned, like, learn something about it or, like, compare things or whatever logic that we need to do. And transforming them into objects that then know how to do math on themselves [laughs] is very cool. JOËL: Hashes are interesting because they're pretty much just basic data structures. And I think, very often, they're sort of pre-objects. They're things that want to eventually become objects. And, oftentimes, what I find is that hashes get passed around a system. And various other classes or subsystems all have bits of logic that act on the hash because the hash can't own that. And so you end up with the logic around the concept of whatever the hash represents kind of scattered and maybe duplicated across three or four places in the application. And then, all of a sudden, if you give that a name, if you create a class for it, you can pull all of that logic into one place. And, all of a sudden, it probably cleans up all of the surrounding places because now they don't have to care about the implementation of exactly what operating on the hash is. But, also, it means that these operations generally have, like, nice domain names. And, in the case of a complex number, you might even have that represented through math operations, like, plus or minus. And that allows your code to read really nicely. STEPHANIE: Right. Which gets me thinking about how I mentioned, like, tally as a noun, and, you know, you implemented your custom class. But do you think there's any value in the idea of a tally being specifically like a hash-like thing with a number as the value for each key, like, that existing as a more general class for people to use? JOËL: Oh, that's interesting. So, in my personal implementation, I hard-coded values for small, medium, and large because those were the T-shirt sizes from the example. But you're talking about some sort of generic tally object that maybe would be a gem or something like that that people could use that represents counts of arbitrary things or multiple counts of arbitrary things that might then implement some common math operators so that you could add or subtract them. STEPHANIE: Yeah, exactly. Because I was just thinking, you know, like I mentioned, I often represent that when I count number of records in my database. Or even I can recall a problem that I encountered previously where I had to figure out the number of orders for an e-commerce store based on the location. And I held that in a hash data structure, but really, it's a tally. [laughs] And so, yeah, I think that maybe we've kind of stumbled across a very useful representation of very common problems. JOËL: Yeah, I can see there being use for a generic version of this. Maybe that's your chance to go out and create some open source, or maybe this already exists. We should maybe research that first. STEPHANIE: Yeah, if any one of our listeners know, [laughs] send us an email. JOËL: So something that was really interesting to me about all of these changes, introducing the value object, cleaning up the reduce, all that stuff, is that, in the end, once the...there was this object that represented the sort of aggregate compound value, the tally, then the equation stayed the same. And I can just slot in those variables as before. Whereas previously, when we switch from just a single count to this, like, we need to take into account sizes that, like, broke the initial implementation of the code. So it's funny how you sort of go from a simple implementation and then a new requirement, which breaks it. But then just changing the hash to be an object all of a sudden made the original code, which didn't really need to change; it just worked again. STEPHANIE: Hmm. That's really interesting because it makes me think about how maybe the primitives were perfectly fine, you know, in the first set of requirements, and not until, like, an additional complexity or something new emerged that we needed to reach for an object that could support the change. JOËL: Yeah. And I think I'd argue that if you're doing just raw T-shirt count, an integer is probably the right value to use there. But if you're doing counts broken out by T-shirt size, then having an object that's a single thing that responds to plus and minus so that you can use it in the same equation where you're saying sum up all of these things from the warehouse, and then do a difference with the T-shirts that we need that becomes really nice. STEPHANIE: Do you think there was some value in going through the hash implementation first, though, and then arriving at using a more custom object? I'm curious, kind of, like, what that journey was like. JOËL: It's hard to say. I would say maybe yes. But I could also see someone who's done this a lot, who's built the sort of heuristics, the instincts around this could immediately be like, oh, wait, we're trying to sum hashes here. Clearly, these need to be objects. Clearly, what we need is something that implements a plus operator that we can reduce. STEPHANIE: Yeah, I like that a lot. Because part of, you know, knowing what to reach for is having seen it enough times and seeing patterns, right? JOËL: This reminds me of a particular pattern that comes from the world of functional programming. It has a kind of scary-sounding name. It's monoid, not monad, monoid. And the idea in the context of Ruby is it's some kind of object that implements a plus method. So two of these objects can combine each other. And typically, you also have some sort of empty version of this object or some sort of, like, zero value. And there's a few rules that go around, like, kind of how this object has to behave. Like, you can't just put any implementation you want in that plus method. Certain requirements that have to be met for it to be considered, like, a valid plus method in this pattern. But if you do meet those requirements, then arrays of this type of object are just inherently reducible because you can just reduce plus over them. And so I think anytime you're trying to aggregate some sort of unwieldy data structure, that's probably a useful pattern to have because, you know, wait, as long as I have a way to combine two items together and potentially some way to generate an empty state, I can aggregate this whole list. STEPHANIE: I'm curious, does that also apply to non-numerical values? JOËL: Yes, any kind of aggregation combination, whatever. So maybe what you're doing is you're combining strings together. STEPHANIE: Got it. JOËL: String concatenation is a form of combination. And so you could be reducing some kind of concatenation over an array of strings, and you end up with one aggregate string that's the combination of all of them. Sometimes, though, you're not just taking values and putting them next to each other so that what you have is kind of all of them at the same time. You might instead do some kind of comparison. An example here might be Boolean values. You might say the way that I'm sort of, quote, unquote, "aggregating" two values, two Boolean values is with the operator AND. And so you have two Boolean values, and you get a new sort of combo value out of them, that is, are both of these values true? STEPHANIE: Whoa, that's blowing my mind right now. Because I had never thought of the, like, AND operator on Booleans, essentially aggregating them into a single true or false value. [laughs] JOËL: It's kind of weird, right? But I guess we do the same thing with numbers. One plus one doesn't give us 11 unless you're writing JavaScript. STEPHANIE: [laughs] JOËL: You know, we get a new number too, that is some sort of, like, combination of the two. So, similarly, it kind of makes sense that two Booleans might combine to create a new sort of third Boolean value. Where it gets really interesting, though, is that once you have this sort of combination, if you try to reduce AND over an array of Booleans, what you effectively have created is Ruby's Enumerable all method that checks to say, are all values in this array true? STEPHANIE: Interesting. But really, the way that's implemented is just, like, a definition of what aggregate means for Booleans, right? JOËL: Right. But it's taking that idea of aggregating two values and scaling it up to an array of many values. So we know Boolean AND. Another way to think about it is, are both of these values true? Is the question it's trying to answer. And then we're scaling that out to say, is both of these values true for everything? So are all of these values true? Because we're going from two to many. STEPHANIE: Cool. So maybe the takeaway for some of our listeners could be, like, next time they find themselves having to deal with a collection or an Enumerable and, you know, using a reduce or, like, trying to break it down to compare two of those elements first, and figuring out how they want that interaction to work. Does that sound right? JOËL: Yeah, absolutely. Once you have a way to combine two elements together, if you want to scale it up to n elements, you just plug it into reduce, and it does the rest of the work for you. My big takeaways from this exercise were one: the value of creating custom objects. Wrapping primitives like hashes in an object and adding a few domain methods on them made such a difference in my final implementation. Secondly, I think it's what you're saying, this whole thing about breaking down complex reduce problems by figuring out how to combine two items and then just using reduce to scale it to an array. And then, finally, I think this is a point that we've mentioned on this podcast before, the value of specific vocabulary - being able to name things and patterns. And so knowing some of the details of this monoid pattern and having a name for it means that now I start seeing it in places. And so the moment I see, oh, wait, we're aggregating values; we're combining two values together and then doing this in a reduce, immediately, my mind goes, wait, that feels like monoid. And then, I can explore that with my custom object to try to make the code better. STEPHANIE: Yeah. And even if you don't remember the monoid part specifically, the idea of Tally, like, that is something that I think is really cool and really applicable to a lot of codebases. JOËL: So, for those who are interested in more practically what this code looks like, I've put this all in a Gist, and I'll link to it in the show notes. This was a really fun exercise for me because I used sort of two development techniques to help sort of build this out. One, I went with a kind of literate programming approach, where I had just a Ruby file and would have put in some big comment blocks talking about what the setup was, what I was trying to do, and then describing how I'd like to use the code, and then try to write code that made that happen. And then, for the actual objects that I was using under the hood, I used TDD to test drive and build them out. So you've got all of that in the Gist. We've got the tests and that sort of literate programming script that almost reads like a mini blog post, except it's executable Ruby. So, if you're curious to see about that, the link is in the show notes. STEPHANIE: That's a very cool format. I'm excited to take a look. On that note, shall we wrap up? JOËL: Let's wrap up. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Joël gives a recap after attending RailsConf 2023 in Atlanta, Georgia (and yes, there was karaoke!

Joël has been integrating a third-party platform into a testing pipeline...and it has not been going well. Because it's not something she usually keeps up-to-date with, Stephanie is excited to learn about more of the open-source side of things in Ruby, what's new in the Ruby tooling world, and what folks are thinking about regarding the future of the language. Today's topic is inspired by an internal thoughtbot Slack thread about writing a custom matcher for Rspec. Stephanie and Joël contrast DSLs vs. Object APIs and also talk about: CanCanCan vs Pundit RSpec DSL When is a DSL helpful? Why not use both DSLs & Object APIs? Extensibility When does a DSL become a framework? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyKaigi 2023 (https://rubykaigi.org/2023/) Mystified by RSpec's DSL? by Jason Swett (https://www.codewithjason.com/mystified-rspecs-dsl-parentheses-can-add-clarity/) Building Custom RSpec Matchers with Regular Objects (https://thoughtbot.com/blog/building-custom-rspec-matchers-with-regular-objects) FactoryBot (https://github.com/thoughtbot/factory_bot) Writing a Domain-Specific Language in Ruby by Gabe Berke-Williams (https://thoughtbot.com/blog/writing-a-domain-specific-language-in-ruby) Capybara (https://teamcapybara.github.io/capybara/) Acceptance Tests at a Single Level of Abstraction (https://thoughtbot.com/blog/acceptance-tests-at-a-single-level-of-abstraction) CanCanCan (https://github.com/CanCanCommunity/cancancan) Pundit (https://www.capvidia.com/products/pundit) Discrete Math and Functional Programming (https://www.amazon.com/Discrete-Mathematics-Functional-Programming-VanDrunen/dp/1590282604) 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: I've been integrating a third-party platform into our testing pipeline for my client. It has not been going well. We've been struggling a little bit, mostly just because tests just kind of crash. Our testing pipeline is pretty complex. It's a lot of one script, some environment variables, does a few things, shells out to another script, which is in a different language. Does a few more things, shells out to another script, maybe calls out to rake, calls out to a shell script. There are four or five of these in a chain, and it's a bit of a mess. Somewhere along in there, something is not compatible with this third-party service that we're trying to integrate with. I was pairing this week with a colleague. And we were able to reproduce a situation where we were able to get a failure under some conditions and a success under other conditions. So these are basically, if we run the whole chain of scripts that call each other from the beginning, we know we get a failure. And if we skipped entirely the chain of scripts that set up things and then just manually try to invoke a third-party service, that works. And so now we know that there's something in between that's incompatible, and now it's just about narrowing things down. There are a few different approaches we could take. We could try to sort of work our way forward. We know a known point where it breaks and then just try to start the chain one step further and see where it fails. We could try to get fancy and do a binary search, like split it in half and then half and half again. We ended up doing it the other way, where we started at the end. We had our known good point and then just stepping one step back and saying, okay, now we introduce the last script in the chain. Does that work? Okay, that pass is great. Let's go one step further; two scripts up in the chain. And at some point, we find, okay, here's the one script that fails. Now, what is it within this script? And it was a really fun debugging session where we were just narrowing things down until we found the source of the bug. STEPHANIE: Wow, that sounds pretty complicated. It just seems like there are so many layers going on. And it was really challenging to pinpoint where the source of the issue was. JOËL: Definitely. I think all the layers made it really complicated. But having a process that we could follow and then kind of narrowing it down made it almost mechanical to figure out where the bug was once we got to a point where we had a known good point and a known bad point. STEPHANIE: Yeah, that makes sense. Kind of sounds like if you are using git bisect or something like that to narrow down the scope of where the issue could be. I'm curious because this is like a bunch of shell scripts and rake tasks or commands or whatever. What would have made this debugging process easier? JOËL: I think having fewer scripts in this chain. STEPHANIE: [laughs] That's fair. JOËL: We don't need so many scripts that call out to each other in different languages trying to share data via environment variables. So we've got a bit of a Rube Goldberg machine, and we're trying to patch in yet another piece in there. STEPHANIE: Yeah, that's really tough. I was curious if there was, I don't know, any logging or any other clues that you were getting along the way because I know from experience how painful it is to debug that kind of code. JOËL: It's interesting because I feel like normally logging is something that's really useful. In this particular case, we run into an exception at some point. So it's more of under what conditions does the exception happen? The important thing was to find that there is a point where it breaks, and there's a point where it doesn't, and realizing that if we ran some of these commands just directly without going through the whole pipeline, that things did work and that we were not triggering that exception. So all of a sudden, now that tells us, okay, something in our pipeline is wrong. And then we can just start narrowing things down. So yeah, adventures in debugging. Sometimes it's really frustrating, but then when you have a good process, and you find the bug, it's incredibly satisfying. STEPHANIE: I like that you used a process that can be applied to many different problems, in this particular case, debugging a testing pipeline. Maybe not something that we do every day, but certainly, it comes up, and now we have tools to address those kinds of issues as well. JOËL: So my week has been up and down with all of this debugging. What's been new in your world? STEPHANIE: I've been doing some travel planning because I'm going to RubyKaigi in Japan. JOËL: Whoa. STEPHANIE: This is actually going to be my first international conference, so I'm really looking forward to that. I just have never been compelled to travel abroad to go to a tech conference. But I'm really looking forward to going to RubyKaigi because now I've been to the U.S.-based conferences a few times. And I'm excited to see how things are different at an international conference and specifically a RubyKaigi because, obviously, there's a lot of really cool Ruby work happening over there in Japan. So I'm excited to learn about more of the open-source side of things of Ruby, what's new in the Ruby tooling world, and just what folks are thinking about in terms of the future of the language. That's not something I normally keep super up-to-date on. But I'm excited to be around people who do think and talk about these things a lot and maybe get some new insights into my own work. JOËL: Do you find that you tend to keep up more with some of the frameworks like Rails rather than the underlying language itself? STEPHANIE: Yeah, that's a good question. I do think because the framework changes a little more frequently, new releases are kind of more applicable to the work that I'm doing. Whereas language updates or upgrades are a little bit less top of mind for me because the point is that it doesn't have to change [laughs] all that much, and we can continue to work with things as expected and not be disrupted. So it is definitely like a whole new world for me, but I'm really looking forward to it. I think it will be really interesting and just kind of a whole other space to explore that I haven't really because I've usually been focused on more of the web development and industry work side of things. JOËL: What's a Ruby feature that either is coming out in the future or that came out in the last couple of releases that got you really excited? STEPHANIE: I think the conversation about typing in Ruby is something that has been on my radar but has also been ebbing and flowing over time. And I did see a few talks at RubyKaigi this year that are going to talk about how to introduce gradual typing in Ruby. And now that it has been out for a little bit and people have been using it, how people are feeling about it, pros and cons, and kind of where they're going to take it or not take it from there. JOËL: Have you done much TypeScript? STEPHANIE: I have been working more in TypeScript recently but did spend most of my front-end work coding days in JavaScript. And so that transition itself was pretty challenging for me where I suddenly felt a language that I did know pretty well. I was having to be in that...in somewhat of a beginner's mindset again. Even just reading the code itself, there were just so many new things to be looking at in terms of the syntax. And it was a difficult but ultimately pretty rewarding experience because the way I thought about JavaScript afterwards was much more refined, I think. JOËL: Types definitely, I think, change the way you think about code; at least, that's been my experience. STEPHANIE: Yeah, absolutely. I haven't gotten the pleasure to work with types in Ruby just yet, but I've just heard different experiences. And I'm excited to see what experts have to say about it. JOËL: That's the fun of going to a conference. STEPHANIE: Absolutely. So yeah, if any listeners are also headed to RubyKaigi, yeah, look out for me. JOËL: I was recently having a conversation with someone about the fact that a lot of languages provide ways to sort of embed many languages within them. So the Lisp family of languages are really big into macros and metaprogramming. Some other languages are big into giving you the ability to build your own ASTs or have really strong parsing capabilities so that you can produce your own, again, mini-language. And Ruby does this as well. It's pretty popular among the Ruby community to build DSLs, Domain-Specific Languages using some of Ruby's built-in abilities. But it seems to be a sort of universal need or at the very least a universal desire among programmers. Have you ever found yourself as a code author wanting to embed a sort of smaller language within your application? STEPHANIE: I don't think I have, to be honest. It's a very interesting question. Because I think the motivation to build your own mini-language using Ruby would have to be you'd have to have a really good reason for it, and in my experience, I haven't quite encountered that yet. Because, yeah, it seems like a lot of upfront work, a lot of overhead to introduce something like that, especially if it's not necessarily either a really, really particular domain that others might find a use for, or it just doesn't end up seeming worthwhile if I can just write regular, old Ruby code. JOËL: I think you're not alone. I think the Ruby community has been kind of a bit of a pendulum here where several years ago, everything that could be made into a DSL was. Now the pendulum kind of has been swinging the other way. And we see DSLs, but they're not quite as frequent. For those who maybe have not experienced a DSL or aren't quite familiar with the concept, how would you describe the idea? STEPHANIE: I think I would describe domain-specific languages as a bit of a mini-language that is created for a very particular problem space in mind to make development for that domain easier. Oftentimes, I've also kind of seen people describe the benefit of DSLs as being able to read that language as if it were plain English. And so, in my head, I have kind of, at least in the Ruby world, right? We see that a lot in different gems. RSpec, for example, has its own internal DSL, and many people really enjoy it because it took the domain of testing. And the way you write it kind of is how you might read or understand it in English. And so it's a bit easier to talk about what you're expecting in your tests. JOËL: Yeah, it's so high-level and minimal and domain-specific that it almost stops feeling like it's a programming language and can almost feel like it's a high-level configuration for this very particular domain, sometimes even to the point where the idea is that a non-programmer could read it and understand what's going on. STEPHANIE: I think RSpec is actually one of the first Ruby DSLs that you might encounter when you're learning Ruby for the first time. And I've definitely seen developers who are new to Ruby, you know, they're writing code, and they're like, okay, I'm ready to write a test now. And the project uses RSpec because that's what most of us use in our Rails applications. And then they see, like you said, almost a configuration language, and they are really confused. They're not really sure what they're reading. They struggle with the syntax a lot. And it ends up being a point of frustration when they're first starting out if they're not just copying and pasting other existing RSpec tests. I'm curious if you've seen that before. JOËL: I've definitely seen that. And it's a little bit ironic because oftentimes, an argument for DSL is that it makes things simpler that you don't even have to know Ruby; you can just write it. It's simpler. It's easier to write. It's easier to understand. And to a certain extent, maybe that's true. But for someone who does know Ruby and doesn't know your particular little domain language, now they're encountering something that they don't know. And they're having to learn it, and they're having to struggle with it. And it might behave a little bit weirdly compared to how Ruby normally works. And so sometimes it doesn't make it easier for adoption. But it does look really good in a README. STEPHANIE: That's totally fair. I think the other thing that's interesting about RSpec is that a lot of it is really just stylistic. I actually read a blog post by Jason Swett and the headline of it was "Mystified by RSpec's DSL? Some parentheses can add clarity." And he basically goes on to tell us that really RSpec is just leaning on some of Ruby's syntactic sugar of omitting parentheses for method calls. And if you just add the parentheses back in your it blocks or your describes, it can read a lot more like regular Ruby. And you might have a better time understanding what's going on when you realize that we're just passing our descriptors as arguments along with some blocks. JOËL: That's ironic given that oftentimes, the goal of these is to make it look like not Ruby. STEPHANIE: I agree; it is ironic. [laughs] MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! JOËL: I think another drawback that I've seen with DSLs is that they oftentimes are more limited in their capabilities. So if the designer of the gem didn't explicitly think of your use case, then oftentimes, it can be really hard to extend or to support edge cases that are not specifically designed for that language in the way that plain Ruby is often much more flexible. STEPHANIE: Yeah, that's really interesting because when a gem does have some kind of DSL, a lot of effort probably went into making that the main interface that you would work with or you would use. And when that isn't working for your use case, the design of the underlying objects may or may not be helpful for the changes that you want to make. JOËL: I think it's interesting that you mentioned the underlying objects because those are often sort of not meant for public consumption when you're building a gem that's DSL forward. I think, in many cases, my ideal gem would make those underlying objects the primary interface and then maybe offer DSL as a kind of nice-to-have layer on top for those situations that maybe aren't as complex where writing things in the domain language might actually be quite nice. But keeping those underlying objects as the interface, it's nice to use and well-documented for the majority of people. STEPHANIE: Yeah, I like that too because then you can get the best of both worlds. So speaking of trying to make a DSL work for you, have you ever experienced having to kind of work around the DSL to get the functionality you were hoping to achieve? JOËL: So I think we're talking about the idea of having both a DSL and the underlying objects. And RSpec is a great example of this with their custom matchers. RSpec itself is a DSL, but then they also offer a DSL to allow you to create custom matchers. And it's not super well documented. I always forget how to define them, and so I oftentimes don't bother. It's just kind of too much of a pain for something that doesn't always provide that much value. But if it were easy, I would probably do it more. Eventually, I realized that you could use just regular Ruby objects as custom matchers. And they just seemed to respond to certain methods, just regular old objects and polymorphism. And all of a sudden, now I'm back into all of the tools and mechanisms that I am familiar with, like the back of my hand. I can write objects all day. I can TDD them. I can apply any patterns that I want to if I'm doing something really complicated. I can extract helpers. All of that works really well with the knowledge that I already have without having to sink a lot of time into trying to learn the built-in DSL. So, for the most part, now, when I define custom matchers, I'll often jump directly to creating a regular object and making it conform to the matcher interface rather than relying on the DSL for that. So once we go back to the test, now we're back in DSL land. Now we're no longer talking in terms of objects so much. We'll have some nice methods and they will all kind of read like English. So to pull a recent example that I worked on, I might say something like expect this policy object method to conform to this truth table. STEPHANIE: That's a really interesting example. It actually kind of sounds like it hits the sweet spot of what you were describing earlier in the sense that it has a really nice DSL, but also, you can create your own objects, and that has an interface that you can implement. And yes, have your cake and eat it too. [laughs] But the idea that then you're kind of converting it back to the DSL because that is just what we know, and it has become so normalized. I was talking earlier about okay; when is a DSL worthwhile? When is the use case a good reason to implement it? And especially for gems that I think that are really popular that we as a Ruby community have collectively used most of the time on our projects because we have oftentimes a lot of the same problems that we're solving. It seems like this has become its own shared language, right? JOËL: Yeah, there are definitely some DSLs that we all end up learning because they're just so prominent in the Ruby community, even Rails itself ships with several built-in DSLs. STEPHANIE: Yeah, absolutely. FactoryBot is another one, too. It is a gem by thoughtbot. And actually, in preparation to talk about DSLs with you today, I scoured our blog and found a really great blog post, "Writing a Domain-Specific Language in Ruby" by Gabe Berke-Williams. And it is basically like, here's how to write something like FactoryBot and creating your own little mini Ruby DSL for something that would be very similar to what FactoryBot does for fixtures. JOËL: That's a great resource, and we'll make sure to link that in the show notes. We've been talking about some of the limitations of DSLs or some aspects of them maybe that we personally don't like. What are maybe examples of DSLs that you do enjoy working with? STEPHANIE: Yeah, I have an example for this one. I really enjoy using Capybara's DSL for acceptance testing. I did have to go down the route of writing some custom selectors for...I just had some HTML elements within kind of a complicated table and was trying to figure out how to write some selectors so that I could write the test as if it were in, you know, quote, unquote, "plain English" like, within this table, expect some value. And that was an interesting journey. But I think that it really helped me have a better understanding of accessibility of just the underlying building blocks of the page that I was working with. And, yeah, I really appreciate being able to read those tests from a user perspective and kind of know exactly what they're doing when they're interacting with this virtual browser without having to run it in headful mode and see it for myself. JOËL: It's always great when a DSL can give you that experience of abstracting enough to where it makes the code delightful to work with while also not having too high a cost to learn or being too restrictive in what it allows you to do. Would you make a difference between something that's a DSL versus maybe just code that's written at a higher level of abstraction? So maybe to get back to your example with Capybara, it's really nice to have these nice custom matchers and all of these things to work with HTML pages. If I'm writing, let's say, a helper method at the bottom of a test, I don't think that feels quite like it's a DSL yet. But it's definitely a higher level than specifying CSS selectors. So would you make a difference between those two things? STEPHANIE: That's a good question. I think it's one of those you know it when you see it kind of questions because it just depends on the amount of abstraction, like you mentioned, and maybe even metaprogramming. That takes something from the core language to morph into what you could qualify as a separate language. What do you think about this? JOËL: Yeah, part of me almost wonders if this exists kind of on a continuum, and the boundary might be a little bit fuzzy. I think there might be some other qualifications that come with it as well. Even though DSLs are typically higher-level helpers, it's usually more than just that. There are also sort of slightly different semantics in the way that you would tend to use them to the point where while they may be just Ruby methods, we don't use them like Ruby methods, and even to the point that we don't think of them as Ruby methods. To go back to that article you mentioned from Jason, where just reminding people, hey, if you put params on this, all of a sudden, it helps you remember, oh, it's just a Ruby method instead of being like, oh, this is a language keyword or something. STEPHANIE: Yeah, I wonder if there's also something to the idea of domain specificity where it should be self-service within the domain that you're working. And then it has limitations once you are trying to do something separate from the domain. JOËL: Right, it's an element of focus to this. And I think it's probably also a language is not just one helper; it's a collection typically. So it's probably a series of high-level helpers, potentially. They might not be methods, even though that is ultimately one of the primary interfaces we use to run code in Ruby. So it's a collection of methods that are high-level, but the collection itself is focused. And oftentimes, they're meant to be used in a way where it's not just a traditional method call. STEPHANIE: Right. There's some amount of you bringing to the table your own use case in how you use those methods. JOËL: Yeah, so it might be mimicking a language keyword. It might be mimicking the idea of a configuration. We see that a little bit with ActiveRecord and some of the, let's say, the association and validation APIs. Those kind of feel like, yes, they're embedded in a class, but they feel like either keywords or even just straight-up configuration where you set key-value pairs of things to configure how a particular class is going to work. STEPHANIE: Yeah, that's true for a lot of things in Rails, too, if we're talking about routes and initializers as well. JOËL: So I've complained about some things I don't like about DSLs. I really like the routing DSL in Rails. STEPHANIE: Why is that? JOËL: I think it's very compact and readable. And that's an element that's really nice about DSLs is that it can make things feel very readable and, oftentimes, we read code more often than we write it. And routes have...I was going to say fewer edge cases, but I have seen some really gnarly route files that are pretty awful to work with, especially if you're mostly writing RESTful controllers, and I would recommend that people do. It's really nice to just be able to skim through a route file and be like, oh, these are the resources in my app and the actions I can do on each resource. And here are the ones that are nested. STEPHANIE: Yeah, it almost sounds like a DSL can provide guardrails towards the recommended way of tackling that particular domain. The routes DSL really discourages you from doing anything too complicated because they are encouraging you to follow the Rails convention. And so I think that goes back to the specificity piece of if you've written a DSL, it's because you've thought very deeply about this particular domain and how common problems show up and how you would want people to be empowered by the language rather than inhibited by it. JOËL: I think, thinking more about that, the word that comes to mind is declarative. When you read code that's written with DSLs, typically, it's very declarative. It's more just describing a thing as opposed to either procedural, a series of commands to do, or even OO, where you're composing objects and sending messages to each other. And so problems that lend themselves to being implemented through more descriptive and declarative approaches probably are really good candidates for a DSL. STEPHANIE: Yeah, I like that a lot because when we talk about domains, we're not necessarily talking about a business domain, which is kind of the other way that some folks think about that word. We're talking about a problem space. And the idea of the language being declarative to describe the problem space makes a lot of sense to me because you want it to be flexible enough for different use cases but all within the idea of testing or browser navigation or whatever. JOËL: Yeah. I feel like there's a lot of... there are probably more problems that can be converted to declarative solutions than might initially kind of strike you. Sometimes the problem isn't quite as bounded. And so when you want customizations that are not supported by your DSL, then it kind of falls apart. So I think a classic situation that might feel like something declarative is authorization. Authorization are a series of rules for who can access what, and it would seem like this is a great case for a DSL. Wouldn't it be great to have just one file you can just kind of skim, and we can just see all of the access rules? Access rules that are basically asking to be done declaratively. And we have gems like that. The original CanCan gem and then the successor CanCanCan are trying to follow that approach. Have you used either of those gems? STEPHANIE: I did use the CanCanCan gem a while ago. JOËL: What was your experience with that style of authorization? STEPHANIE: It has been a while but I do remember having to check that original file of like all the different authorizations kind of repeatedly coming back to it to remember, okay, for this rule, what should be allowed to happen here? JOËL: So I think that's definitely one of the benefits is that you have all of your rules stored in one place, and you can kind of scan through the list. My experience, though, is that in practice, it often kind of balloons up and has all of these edge cases in it. And in some earlier versions, I don't know if that's still a problem today, it could even be difficult to accomplish certain things. If you're going to say that access to this particular object depends not on properties of that object itself but on some custom join or association or something like that, that could be really clunky to do or sometimes impossible depending on how esoteric it is or if there's some really complex custom logic to do. And once you're doing something like that, you don't really want to have that logic in your...in this case, it would be the abilities file but inside because that's not really something you express via the DSL anymore. Now you're dropping into OO or procedural world. STEPHANIE: Right. It seems a bit far removed from where we do actually care about the different abilities, especially for one-off cases. JOËL: That is interesting because I feel like there's a bit of a read-versus write-situation happening there as well. It's particularly nice to have, I think, everything in one abilities file for reading and for auditing. I've definitely been in code where there's like three or four ways to authorize, and they're all being used inconsistently, and that's not nice at all. On the other hand, it can be hard with DSL sometimes to customize or to go beyond the rules that are built in. In the case of authorization, you've effectively built a little mini-rules engine. And if you don't have a good way for people to add custom rules without just embedding procedural code into your abilities file, it's going to quickly get out of hand. STEPHANIE: Yeah, that makes sense. On the topic of authorization, you did mention an example earlier when you were writing a policy object. JOËL: I've generally found that that's been my go-to pattern for authorization. I enjoy the Pundit gem that provides some kind of light scaffolding around working with policy objects, but it's a general pattern, and you can absolutely write your own. You don't need a gem for that. Now we're definitely not in the DSL world. We're not doing this declaratively. We're leaning very heavily on OO and saying we're just going to create objects. They talk to each other. They can do anything that any Ruby object can do and as simple or as complex as they need to be. So you have the full power of Ruby and all the patterns that you're used to using. The downside is it is a little bit harder to read and to kind of just audit what's happening in terms of permission because there's no high-level overview anymore. Now you've just got to look through a bunch of classes. So maybe that's the trade-off, flexibility, extensibility versus more declarative style and easy overview. STEPHANIE: That makes a lot of sense because we were talking earlier about guardrails. And because those boundaries do exist, that might not give us the flexibility we want compared to just writing regular Ruby objects. But yeah, we do get the benefit of, like you said, auditing, and at least if we don't try to do some really gnarly, custom stuff, [laughs] something that's easier to read and comprehend. JOËL: And, again, maybe that's where in the best of both worlds situation, you say, hey, I'm creating some form of rules engine, whether it's for describing routes, or authorization, permissions, or users can build custom business rules for a product or something like that. And it's all object-based under the hood. And then, we provide a DSL to make it nice to work with these rules. If a programmer using our gem wants to write a custom rule that just really extends what the ones we shipped can do, allow them to do that via the object API. We have all the objects available to you that underlie the DSL. Add more rules yourself. And then maybe those can be plugged back into the DSL like we saw with the RSpec and custom matchers. Or maybe you have to say, okay, if I have a custom rule object, now I have to just stay in the object space. And I think both of those solutions are okay. But now you've sort of kept those two worlds separate and still allowed people to extend. STEPHANIE: I like that as contributing to the language because language is never static. It changes over time. And that's a way that people can continue to evolve a language that may have been originally written at a certain time and place. JOËL: Moving on from DSLs, we got some listener feedback recently from James, who was listening to our episode on discrete math. And James really appreciated the episode and wanted to share a resource with us. This is the book "Discrete Math and Functional Programming" by Thomas VanDrunen. It's an introduction to discrete math as a theoretical concept taught side by side with the very practical aspect of learning to use the language standard ML, and both of those factor into each other. So you're kind of learning a little bit of theory and some practice, at the same time, getting to implement some discrete math concepts in standard ML to get a feel for them. Yeah, I've not read this book, but I love the concept of pairing a theoretical piece and a practical piece. So I'll drop a link to it in the show notes as well. Thank you, James. STEPHANIE: Yeah, thanks, James. And I guess this is just a little reminder that if our listeners have any feedback or questions they want to write in about, you can reach us at hosts@bikeshed.fm. JOËL: On that note. Shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager. They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after. How does that affect the tests? How does that affect the code? How does that affect workflow? Are you a "better" programmer because you 100% TDD? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Cassidy William's Productivity tools (https://dev.to/cassidoo/the-productivity-apps-i-use-in-2023-3m8l) raindrop.io Bookmark Manager (https://raindrop.io/) Simplifying Tests by Extracting Side-Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) 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 is new in your world? STEPHANIE: It's gardening season here in Chicago. So right now, it is like mid-April as we're recording this, and we are just starting to get some warm weather. And this is usually the time that I do my garden planning for the season. And the other week, I went over to a friend's place, and we did a bit of a seed share. So we just each have collected fruit and vegetable seeds and herbs and all that. And a really fun way to collect more things to grow is to share with your friends. Seeds are super cheap, but I feel like you could just have like an infinite amount for all of the things that you might want to grow. And so it's really nice to be able to, yes, spread that gardening love around and share with your friends. JOËL: I'm imagining something like people trading collectible trading cards but the plant version. STEPHANIE: Yeah, exactly. The fun thing that we did, my friend and I, because, you know, you usually get a little envelope with between 10 and 50 or more seeds, and they're super tiny. Some of them are really teeny tiny, like with broccoli, for example, it's like I can't even explain. It's less than a millimeter, I swear. It's very easy to just lose them, so you want to keep them contained. But because we are sharing, we don't have a second envelope for the other person to take home with them. And so we actually made our own little envelopes with some origami paper that she had. And we folded it and stapled it and made it very cute. And so I came home with a bunch of these very adorable handmade envelopes with all of my new seeds. JOËL: Are you mostly doing vegetables, or are these flowers? STEPHANIE: Yeah, so we mostly focus on vegetables for our garden. And we do like to sprinkle some flower seeds in our yard. But that is more just like throw some seeds out there, and whatever happens to them happens. But with the vegetables, we put a little bit more effort because we usually try to have a good yield. So in past years, that has meant starting seeds indoors because, in Chicago, we have a shorter growing season than some warmer climate places. And the late summer vegetables like tomatoes, peppers those usually take a little bit longer. So if you want to get a good yield, you might want to start them inside a little early before it's warm enough for them to go outside. JOËL: So, do you have a garden plot out in your yard, or do you have a community garden plot? How does that work? STEPHANIE: I am really grateful to have a bit of backyard space. And we have three raised beds that we built that cover...I think each one is 3 feet by 10 feet, so quite a good amount of space. Yeah, we're able to grow a lot of food. Our highlights include shishito peppers. That's one that I really like to grow myself a lot because I usually don't see them in stores as frequently. We grow really great eggplants. Tomatoes, obviously, is a pretty popular beginner-friendly vegetable plant. And we like to grow a lot because then we can process it all and can some of it so we can have nice tomato sauce that's homegrown year round. JOËL: Hmm, sounds delicious. Do you experiment with the different varieties? STEPHANIE: We do. That's also a way that the seed sharing is really helpful because maybe I'll get some varieties of certain vegetables like cucumbers or whatever, but maybe my friend has a different kind. And I think we try to do a mix of growing the varieties that we know we like and then experimenting with some ones that are new to us. JOËL: It's hard to beat fresh vegetables in the summer. STEPHANIE: Yeah. I'm very excited, especially because during the fall and winter seasons here in Chicago, our local food is a little less exciting. It still can be good, but it's been a lot of root vegetables and the like when we try to eat seasonally in the other season. So I'm really looking forward to stuff that's just juicy and fresh, and it's just one of my biggest joys during the summer. What about you, Joël, what's new in your world? JOËL: I've recently started experimenting with a dedicated bookmark manager. This is not because I have been to too many bookstores and have all the free bookmarks they give you. These are the digital bookmarks to websites, and I've been really bad at managing those. I mostly just memorize the keywords I need to Google to get access to that website, which is a terrible way of doing things. And then I've got a mix of a few different browsers, which I don't sync, and have a couple of bookmarks. I use a little bit of Pocket, which is a tool by Mozilla. It's all right, but the search capabilities are not very good. So sometimes I'll know it's in there, but I can't find it. STEPHANIE: I'm so glad you brought up this topic because I am in a similar boat where I read a lot of things on the internet and have just thrown them all into my top-level bookmarks hierarchy. And that has not really been working for me, either. So I'm really curious to find out how you've been solving this problem. JOËL: So recently, I volunteered to be a mentor for first-time speakers at the upcoming RailsConf in Atlanta. And someone was asking me about designing slides, and we were talking a little bit about when should you use maybe a bulleted list on a slide versus when there are other options available. I knew that I had read years ago a fantastic resource on slide design. But try as I could, I could not Google this and get the page that I was looking for. This was shared to me by somebody else as part of a conference preparation group years ago, and so I reached out to this person. I was like, "Hey, so do you happen to remember that link you shared with me five years ago?" And this person says, "I do remember it. I don't have the link either." STEPHANIE: I've literally been in this exact same situation where I remembered that there was an article that I read, and I remembered exactly who shared it with me or who I talked about it with, and when I couldn't find it, trying to reach out to them and also not being able to find it through them. JOËL: So the story ends well because I was able to log into an old Slack group... STEPHANIE: Wow. JOËL: That had been created for the speakers at this conference and dig through the history. And luckily, I still had access to the group. I was still in that private channel for the speakers. And I found the link, and I was able to share it with others. So that was great. But then I started thinking; I can't keep living this way. I need something better. STEPHANIE: It's true. Even though we are expert Googlers as developers, sometimes the search just doesn't get you the thing you're looking for. JOËL: So, about this time, I'm scrolling Twitter as one does. And I saw a tweet from Cassidy Williams talking about some of the productivity tools that she's been using this year did a longer article about it. And I started reading it, and a tool that she mentioned there is Raindrop.io, which is an all-in-one bookmark manager. And I'm like, oh, that is exactly, I think, the missing piece of technology in my life right now. So I went up and signed up for it, and so far, it's been pretty good. I'm experimenting with it. But I've consolidated a lot of the links that were in my head or in some of these other places, put it in there, categorized them a little bit, tagged them. And hopefully, this becomes a better way so that when I want to reference a link for someone else either in a conversation or as a resource or even for myself, maybe when I'm writing an article, I'm like, oh, I know I read something that would act as a good resource here. I can go to Raindrop and get that article without any of these other shenanigans I had to do this time. STEPHANIE: Amazing. What is special about Raindrop as opposed to just your native browser bookmark capabilities? JOËL: It has some deeper structuring capabilities in terms of not everything has to be hierarchical. It has tags as well as categories. And I think most importantly, for me, it has search, which seems to be pretty good at surfacing things. It also has some somewhat smart capabilities where it will automatically figure out if the thing that you've linked is an article, or a document, or a video, something like that. So you can filter by these inferred types as well. It has the ability to sync across devices, which browsers can do if you're signed up for them. STEPHANIE: Nice. I like that it has that search functionality that you mentioned because I think I'm definitely in the boat of just scrolling through all of my untagged, unorganized bookmarks. And it's really tough to find what I'm looking for, especially if the meta title also doesn't quite tell me exactly the keywords that I'm needing to be scanning for in that moment. So I will definitely have to give it a try. JOËL: I believe you can get full-text search if you pay for the premium version (I'm currently trying the free version.), which in theory, could mean that it searches the contents of the article. It's not clear with that. But I do know they save a snapshot of the text of the article. STEPHANIE: That's really interesting because then it's almost like a search engine but scoped to the things that you have saved. JOËL: Yes. STEPHANIE: Nice. JOËL: I'll see how that goes, and maybe six months from now, I can talk a little bit about what the experience has been using that. STEPHANIE: Yeah, six months from now, you can tell us all about how you have no issues or qualms with how you've been managing bookmarks because everything is working perfectly well for you. [laughs] JOËL: JK, I've dropped this whole bookmark thing. STEPHANIE: That's true. That's also the flip side of trying out a new tool, [laughs], isn't it? MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: So our topic for today is something that we've had in our topic backlog for a while, and I'm excited to talk about it. It's TDD, which I think is a very well-known, potentially controversial topic of discussion in the world of software development. And specifically, we wanted to talk about when TDD is useful and when you actually might also have some value in writing tests afterwards. And in preparation for this topic today, I actually have been TDDing most of my client work this week. JOËL: What? You're telling me you don't TDD 100% of the time? Are you even a real developer? STEPHANIE: I am a real developer, and I do not TDD 100% of the time. I'm just going to say it. It's on record. JOËL: You know what? Me too. STEPHANIE: Wow, I'm glad we could clear the air on that one. [laughs] JOËL: What percent of the time would you say that you do TDD? In this case, test first as opposed to maybe testing after you've written the code or maybe not testing at all. STEPHANIE: Hmm, that's an interesting question. A part of me wants to answer it in my ideal workflow terms. But I think that is less interesting than reality, which is I will usually at least try to test first if I'm feeling like I am up for it. So maybe the percentage is, I don't know, I really couldn't tell you, but I'm just going to throw out 40% of the time [laughs] because that seems pretty, I don't know, reasonable. Sometimes you wake up, and you're just like, I'm not going to do it today. [laughs] And other days, you wake up, and you're like, you know? It sounds like a fun exercise to do for this particular feature. So yeah, if I TDD 40% of the time, then I think maybe I write tests after another 40% or 50%. And then [laughs] I'm hesitant to say this on the air, but sometimes you code, and you don't write tests for it and would not recommend it for the majority of your work. But I'm just going to be real here that sometimes it happens. JOËL: It's always a trade-off in terms of the work you put in versus the value you're getting out of it. And sometimes, you get very little value out of a test. STEPHANIE: Yeah, that's real. It totally depends on what you're doing. JOËL: I think one thing that's interesting for us, because we're consultants, so we move from one project to another, is that some projects are set up in a way that they're very test friendly. It's easy to have a testing workflow with them. And then others are just incredibly painful to test because of the way the system has been architected. And I think a TDD purist would then tell us that this is a symptom of high coupling or other architectural problems; that's probably true. But also, you don't have time to re-architect the entire system, and so then it becomes a question of trade-offs. Can I test some things easily today? Can I refactor a few things that will make this local change somewhat easier to test? And then, where is it not worth the effort to make something testable? STEPHANIE: Yeah, I've definitely struggled with that, where a part of me wanted to test something very thoroughly or even do test-driven development and then ran into some obstacles along the way and having to be realistic about that effort. The other thing I was referring to around it depending is also the actual code you're working on. So maybe if you're just writing a script or something to automate some dev workflow, it's okay for that not to be tested. And I also do think that the decision to TDD is very dependent on whether you are writing net new code, or refactoring, or having to deal with legacy code. JOËL: That definitely makes a difference. For me, when I'm refactoring in the purest sense, changing structure without changing behavior, in theory, I should not be writing tests for that because there should already be existing tests, and I'm not changing behaviors. So the test suite should prove that my changes did not change behavior. In practice, oftentimes, there is not the coverage that needs to be there. I don't know about you; I feel like I often don't trust the code enough, where I'm a little bit scared to do a refactor if there isn't test coverage. How about you? STEPHANIE: I've been running into that issue a lot on my current client project where I've been making an intentional effort to add test coverage before I make any changes because that forces me to really understand how things work because either I read a piece of code and I just can't tell at all. Or I learn later on that I thought I understood something based on the class or the method names, but it turns out that there was actually some nuance in there or side effects or what have you that belied my understanding [laughs] of what it was doing. And after a few times of that lack of trust that you talked about popping up, I was like, okay, I think, at least for me, the way that I can feel good about the work that I'm doing is to set myself up for success in that way. JOËL: Do you ever find that the code that you write in a test-driven approach tends to end up different than code that you might write with a test-after approach? STEPHANIE: Yeah, I think this can actually be answered at a few different levels but let me start with talking about how I like to practice TDD. If I'm given a user story, I usually try to work outside in. So I will write a feature or acceptance test and that involves testing how the user would interact with our application. At that point, I will usually go with the most naive implementation to get the test passing, and so it probably won't look pretty. In a recent case, I was adding a new parameter to a controller, and I just put everything in the controller to get the test green. [laughs] And then, at that point, is when I gave that code a second pass and looked for areas to extract where I could. JOËL: That refactor step and the red, green refactor cycle is really important. STEPHANIE: Yeah, absolutely. I think that is where I find TDD to be the most valuable from that higher-level perspective. And I know that there are different schools of thought on this. But that helps ensure that at least I have written the code to make the feature work the way that I was hoping. And I use TDD less for driving design decisions just because I like to have something to react to that is helpful for me rather than having a blank slate of, okay, let me write a test with an idea about how an object's interface will look. And so that's what works for me. So I do think it's kind of a mix of like from an acceptance test level; I am at least writing code that I know works, but the shape of the code for me is less determined by how I test. JOËL: So when you're looking at code that you've written six months down the line, you generally can't tell the difference whether it was test-driven or written first and tested after. STEPHANIE: That sounds right. That's just how my process works. In fact, I think recently we, to go on a quick tangent, we talked about writing conference talks, and I think I even mentioned for me the process is looking at the thing and then revising. And I think that the design driving element of TDD that a lot of people like is a bit less effective for me personally. JOËL: Hmm. Would you say that TDD does not impact the shape of the code that you end up creating in response to the tests? Or when you're talking about design, are you mostly thinking in terms of the interface that you would have in the test itself, like, what arguments the constructor takes or things like that? STEPHANIE: I think I was talking more about the latter, the interface, the construction arguments. When I do test afterwards, I also will notice the way the setup of my test how that is feeling. And if it is feeling a bit unwieldy or is a bit complicated, that will cue me to maybe take another pass at the code itself. So that's actually one way that testing after can signal to me a way that I might want to change my code. JOËL: Okay, so you're getting some of those pressures that you get from testing, but you respond to them in a like second path? STEPHANIE: Yeah, I think so. I'm curious how you TDD and whether you notice changes in how your code looks. JOËL: I think there are a couple of things that TDD does in my workflow that are really nice. One is it keeps me focused in terms of getting the work done because you're just following from one failure to another. It also keeps me focused in terms of scope. It's really easy for my engineering brain to be like, oh, we could totally do this thing and all that, and it's like, no, that's not needed to solve the problem at hand. Because in TDD, you try the smallest solution that will solve your problem, and then you will refactor it to make it maybe nicer to work with. But you try not to add new behavior that's not required in order to pass the test, and that can be a really helpful forcing function for me. STEPHANIE: That's interesting because I was just thinking about how sometimes, at least with the outside-in approach that I was talking about, I will find that the scope of the ticket is too big as I make changes to get the desired quality of the code that I want. Like I mentioned, the naive implementation, like, sure, maybe everything is in a controller, but as soon as I'm starting to do that second pass, and I want to maybe change another class and to make it work for my needs, I will notice it start to sprawl a little bit. And that is usually a signal to me that, like, oh, maybe what I need first is just refactoring the objects that I'm hoping to use to get the desired implementation. And that ends up being a separate PR that I do first to then set myself up for making the change. JOËL: The classic make the change easy before you then go and make the easy change. STEPHANIE: Right. But that does mean that that initial feature test that I wrote won't ever be green. So I do have to kind of like back out of making that change and just be like, okay, today is not the day [laughs] that I'm going to get this feature working. JOËL: There are some times where I'm in a situation like that, and I will kind of recognize, oh, there's a refactor step that's happening right now as a sort of subtask. And so, I will make that refactor change that I need to and then commit only those files that were a part of that refactor and may be included as part of the PR with the feature change or maybe push it up and make it its own PR. But depending on what the refactor is, oftentimes, I can kind of do it sort of all more or less continuously but decide once I've done that refactor step, okay, commit time but only those files for the smaller set of changes, and then keep moving with that outside-in approach. One thing I have noticed about the style of code that I tend to produce when I TDD versus when I don't is how I will tend to decouple things. And so because coupled code is really annoying to test in isolation, TDD sort of forces me to do more dependency injection, passing objects to others. It will often force me or maybe not force me, but it gives me that wholesome pressure to maybe separate HTTP requests from more of the business logic in my code, which otherwise I might completely intermix because it's just so convenient. Even certain things like class methods, I might tend to overuse them or use them more if I'm not test driving than if I were. STEPHANIE: When you talk about coupling, I'm curious, do you end up mocking a lot in the tests that you are writing to drive your development? JOËL: No, but if I'm testing after, I probably will. Mocking, I think, is a sign of coupling generally. In tests where you're just passing objects to each other, generally, you can get away with passing in a test double or something, whereas if you're hard-coding dependencies, you often have to mock. STEPHANIE: Got it. That makes a lot more sense now. I think that does require a bit of thought upfront about what kinds of objects you might need and what they would provide for you in the thing that you're testing. JOËL: Yes. There's definitely a phase where let's say; I'm testing some kind of third-party integration; I'm just kind of trying to do it all in one object that has a mix of business logic and some HTTP request stuff. It gets really annoying as we're adding...maybe the first feature is okay. I use WebMock, and I stub out a request, and it's good. And then the second one, I feel like I'm kind of duplicating that. And then the third one, I've got to deal with retries. So now I've got to go back to the first one and add some two or three WebMocks because now we've got exponential backoff code that's happening here. And this new feature broke the old tests. And it just becomes this really annoying thing to do. And then I might start thinking, okay, how do I separate these two things? I have one place where I test the HTTP logic, the exponential backoff, the what to do if I get a 404 from the API. And then, separately, I can just have the business logic and test all of those branches there without having to touch any of the HTTP stuff. I think you could get there from a few different paths. So you could get there by sort of following a lot of classic design principles, things like SOLID, because they kind of converge on that general idea as well. You could even get there if you took more of a functional programming approach where you are really good at separating side-effectful code from, I'm going to use the term loosely here, pure functions. I've heard some people make the distinction between IO versus non-IO in code and how that affects the types of tests that you write for them. And separating those two is a thing that you might do, even if you weren't writing tests at all, if that's a design principle that you know to follow. STEPHANIE: Yeah, that's a great point. I was thinking, as you were talking about your approach for handling that potential feature with talking to a third party, that I've heard that particular task or problem in software development used as an example for a lot of those different techniques or strategies that you mentioned. And I suppose TDD really is just a tool, and it doesn't replace your experience or intuition. And earlier, when we were talking about times that you don't do TDD, I will have to say that if I am doing something that I've done many times before, I feel confident enough that I don't need to lean on that red, green refactor cycle. At that point, it's more muscle memory. And maybe I do forget a step along the way, but I have the experience to know how to debug that or to see the error and know exactly what it was that I did wrong. And in that case, I am tapping into something different than using TDD. JOËL: I think definitely, for a lot of things now, there are patterns that I have learned where even if I weren't TDDing, I might do a third-party integration using this pattern because I've done it via TDD enough to know that this is a structure that I find works very well in terms of the coupling of things. And then maybe if I want to fill in some tests afterwards, then I'll thank my past self that I'm using a pattern that plays nicely with that. One thing that I do notice happens sometimes is that when people add tests after the fact, they will add tests that are green but that don't necessarily fail if the code breaks. Have you ever seen that? STEPHANIE: I have seen that before. In fact, I just saw it recently where we had a false positive test. And I made a change expecting the test to fail, and it didn't, which is not great because the value that tests have are when they fail, you want to be alerted when something goes wrong. Just because they're green doesn't mean that everything works. It just means that they didn't detect a problem. And in this particular case, I don't know if the developer who wrote this test had TDDed or not. But I did notice that in the test, we were mocking a method, and that ended up being the cause of the false positive. JOËL: I'm always a little bit skeptical of mocks because I feel like I've seen so many either brittle tests or tests that will succeed all the time come out of mocks. I don't know if you've ever heard the term tautological test or a test that is a tautology. STEPHANIE: No, I haven't. What does that mean? JOËL: In its sort of most basic sense, it's a test that is always green no matter what the output is. Some people think of it more in terms of self-referential tests, like, oh, a thing equals itself, which, yes, it does, and those tend to be always green. But it's not always self-referential. It can be some other subtle ways. Typically this happens when mocking or specifically if you mock the system under test. It's very easy to write a test that is now going to always be green, no matter how the code changes. A fun fact about the word tautology is it comes from discrete math, which is the topic of my RailsConf talk. If you write out a truth table that shows all the possible inputs and whether or not something will be true or false, depending on what the inputs are, the output column is all true in a tautology, which tells you that no matter what the inputs are, you're going to get true out of that method or function or equation. And so, if this was a Boolean expression in Ruby, you could replace that by hardcoding true and get the same result. STEPHANIE: Yeah, that's what I was imagining, a function that just returns true. [laughs] JOËL: And that's effectively what you can accidentally write when you're creating a test that is a tautological test is one where you could have just replaced the entire thing with expect true to be true, and it would have the same effect. And, like you said, tests only have value when they fail. And a test that never fails has no value. So TDD has this red, green refactor cycle. I feel like you could probably come up with a cute slogan like that for a testing-after style. So maybe I guess you'd start off you write some code, then you write a test that theoretically passes for it. So you start green, but then you want to make sure you see that test fail, so you got to go red and then comment out the code or something. Then comment it back in to see that it goes back to green to make sure that not only does this test fail when the code is broken but also that bringing this test back is what makes it pass, which is an important distinction. So maybe it's a green, red, green, and then maybe refactor. Because one thing that I admired in the style that you were talking about earlier is that even when you test after, you include a refactor step. The test at the end is not the final step in your workflow. STEPHANIE: Yeah, that's a really good point. When you said green, red, green, I was thinking of a Christmas garland [laughs] or something like that. But yeah, I do think that stuff gets skipped sometimes. If you are testing after, you're backfilling tests for code you wrote, and at that point, you think you know how it will work, and so you're writing your tests kind of colored with that in mind. I like the injecting commenting something out or changing an input or something that you know should make the test fail, just so that you can confirm that you didn't just write a test that expects true to equal true or give you a false positive like that, then go back to green. And as you were saying that, it did make me think like, oh, well, that's like a whole extra step as opposed to TDD where we do just have red, green refactor. We don't have that extra step. But I think the effort is just like put in at a different point in time. JOËL: Agreed. It's important that you see the code fail and that you see it pass after the change. The order has changed a little bit, but those two kinds of core elements are present. Kind of by default, you have no choice when you're doing TDD. You have the ability to skip that if you're testing after, but ideally, you incorporate those in a robust test after workflow as well. STEPHANIE: Yeah. And I know I mentioned times when I've done something enough or used a pattern enough that maybe I'll just go ahead and implement it and then backfill with tests. And I also recognize that in those moments, I could have done something wrong, that there is some amount of wanting to check that the test failed. And I imagine there is some kind of balance to achieve there between the speed that you get by having that experience and knowing the direction you want to take things and applying a pattern that you've done a lot with being like, oh, we're all human, and sometimes we make mistakes. JOËL: In a situation where you feel like you're coding something that you've coded up 100 times before, you're very familiar with this. Do you find that a test after workflow is faster for you? STEPHANIE: Hmm, that's an interesting question. JOËL: Because I think that's often a motivation. It's like, I don't want to bother, like, I just have the idea. I know what to do. Let me just write that code and get it done. STEPHANIE: I think if I were introducing a new route or controller action or whatever, I don't need to go through the cycle of writing a test and it failing because I haven't added the action to the controller yet. It's like I know that that is the next logical step, and so maybe I might skip it there. But if I'm at the point where I'm working with business or domain logic, I think that's where is the value of test writing first because it's like, I passed the framework and passed my tools. And now, I'm working at working through the logic of the business problem itself. JOËL: So you're working in maybe slightly larger iterations of that red, green refactor cycle. STEPHANIE: Yeah, that's a good way to describe it. JOËL: I was recently working on a gem and tried to TDD it from scratch and went with micro iterations. And it was actually really fun, and there was a flow to it. And this is a greenfield side project. And it helped me stay focused. I think it did give me a decent design. I really enjoyed it. STEPHANIE: Nice. Was there something satisfying about seeing that green each time and kind of doing that bit of mechanical labor? And I can see how that can feel almost meditative. JOËL: Yes. And I think also because this was a problem that I didn't fully know how I was going to solve, TDD helped really focus me on solving sub-parts of that problem, things that I can hold in my head and solve in a minimalistic way and then iterate on. STEPHANIE: I like that a lot. You were using that technique, and that really helped for the task at hand, which was, in this case, a bit smaller in scope. I think the way you and I have been talking about TDD has been very realistic and very reasonable. And I'm curious what you think about people who kind of use it as the pinnacle of how you should write code. JOËL: I think that's really interesting because TDD is a really wonderful technique, and I wish more people used it. But it's kind of taken on a mystique of its own where if you do TDD or claim to do TDD 100% of the time, now, all of a sudden, you've put yourself on another level. And I think people even who choose for pragmatic reasons not to TDD all the time maybe feel a little bit of guilt or at least feel the need to explain themselves to other people to say, "Hey, I didn't TDD this here. Well, let me explain to you why that's okay, and I'm not a bad programmer." STEPHANIE: Yeah, I think we even alluded a little bit to that earlier in the show, and I could hear my hesitancy to be like, oh, I guess I'm going to say this and have all these people hear it. But I think that's a good point that it's okay for you not to do it 100% of the time. That doesn't make you any less of a programmer. Also, the way we've been talking about it also makes it sound like one of those things where it's like you do have to learn the rules before you can break them. And so there is value in learning it and doing it. And then you also, after having done it enough, know when you want to use it or when you don't. My advice for folks who haven't really done it before or don't quite see the value of it is just to try it and then decide for yourself. I think at the end of the day, we should all feel empowered to be able to decide how we work best. JOËL: It's also really valuable, I think, to maybe pair with someone who is really good at that and to get to see what their workflow is like. Oftentimes, there's almost a hump of getting into it where you are more productive without TDDing because you're not comfortable with the flow or with the techniques. And it takes a lot of expertise to get over that hump where maybe at the expert end of things, you are more productive with it. And on the less expert end, it just becomes a chore that takes up all of your time or ends up giving you results that aren't that great anyway. And so, how do you cross that chasm? STEPHANIE: Yeah, that's a really, really great point because, in some ways, when you first get started, it will feel slow. You are unlearning the ways that you have known to code before and trying to do it in a different way. And I really like your advice about trying to pair with someone who has expertise or has been practicing it for a long time. That was my first real introduction to it too. At this point, I had been a few years into my career and hadn't really tried it because it seemed very daunting, and seeing someone else verbalize their process and seeing their workflow was really helpful for me to get on board. JOËL: I think what I would like is for TDD to be a tool that is aspirational for a lot of people. If you're new to the technique and you've paired with somebody who's really good at it, and you see the flow that they have and be like, wow, that's really good. I would love to get that incorporated in the way that I work. Rather than a sort of measuring stick for how elite of a programmer you are. There's no sense in shaming people over the tools they use. STEPHANIE: Right. Because it should also be accessible, and if you make people feel bad about it, and then it's not accessible to folks. JOËL: On that note. Shall we wrap up? STEPHANIE: Yeah, let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

What you'll learn in this episode: Why Google's search results page is more important than your website homepage Why the most successful law firms are involved in their marketing, even when they hire an outside agency How a firm's intake process can make or break their SEO efforts Why content marketing today is about quality, not quantity Why consistent Google reviews are the key to ranking higher About Stephanie Chew: Stephanie Manor Chew is award-winning law firm analyst andDirector of Sales and Head of the Elite Sales Team at Digital Law Marketing. For the last 16 years, she has been helping clients build credibility and increase their visibility online through the full lifecycle of digital initiatives. From custom search engine marketing and social media positioning, to targeted content and online reputation management, she makes sure that DLM clients get what they need, when they need it. Additional Resources: Digital Law Marketing Website  Stephanie's LinkedIn Digital Law Marketing Facebook Transcript: Gone are the days when you could simply outsource everything to an SEO agency and expect results. To rank on Google today, law firms must take an active role in overseeing and executing their marketing plan. Stephanie Chew, Director of Sales at Digital Law Marketing, finds that the company's most successful clients collaborate with them to achieve the best possible outcome. She joined the Law Firm Marketing Catalyst Podcast to talk about why content is no longer king; why a firm's intake process is the most important part of lead generation; and how consistent Google reviews can boost your SEO efforts. Read the episode transcript here. Sharon:          Welcome to the Law Firm Marketing Catalyst Podcast. Today, my guest is Stephanie Chew. She is the Director of Sales at Digital Law Marketing, and she's speaking to us from Annapolis, Maryland. The company is headquartered in Nashville but is basically a virtual firm and works all over the country. Digital Law Marketing encompasses a wide range of digital aspects today, and no law firm can live without them. From SEO to PPC to social media, a law firm can make a case for each of them, especially when they work together. Today, Stephanie is going to educate us on what's new in digital law marketing, where we should start and what we can't live without. Stephanie, welcome to the program.   Stephanie:    Thank you so much for having me. I'm happy to be here.   Sharon:          Stephanie, tell us your background. How did you end up doing this? You didn't tell your mother this is what you wanted to do where you were little, I don't think.   Stephanie:    It's funny; I always wanted to be in advertising in some respects. I was just telling my daughter this the other night when we were watching the Super Bowl. Watching the Super Bowl with my father, I was always so fascinated by the ads, and I always knew I wanted to do something around advertising and marketing. After college, I started with Trader Publishing Company, which is now Dominion Enterprises. It has changed hands a couple of times, but it's basically selling advertising space to car dealers. Then it turned into apartment communities, like for-rent magazines, things of that nature, and then that led me over to the SEO world, the website world. Then I started working with law firms in 2009, and I've been here ever since.   Sharon:          That's a long time with law firms. I can relate. I wonder what would have happened if I had been in advertising when SEO started. I'm involved in SEO, but I thought advertising was my dream job and quickly found it wasn't. What would you say that lawyers have to do differently in digital marketing?   Stephanie:    They have to be a part of the partnership. In the first part of my career, we would come in and help firms and companies by putting ads in newspapers or books, and the firm or the business really didn't have to do much. Now the most successful firms out there are involved with their marketing, maybe not as much as we are, but they're a pretty big part of it. More than they ever have been. For instance, getting reviews is incredibly important now, so the firm has to work to get reviews. We can make a firm tell Google how amazing the firm is. We can create an amazing website with wonderful content, great SEO strategy, but if the firm isn't getting reviews, they're not going to get business. Now, more so than it's ever been, the firm has to be behind the digital focus and be a part of what their partners are doing to help them become successful online.   Sharon:          That's interesting, because when I read a review, the first thing I look at is, “Is this a legitimate review or is something the company wrote?” I hadn't thought about how involved lawyers have to be, how involved everybody has to be. It's not just something done in the back room.   Stephanie:    Right. The firms that are the most successful online, the lawyers are actually asking for those reviews directly themselves. We've seen firms where they've hired people to get reviews for them. They're never as successful as the actual attorney asking for that review themselves. So, asking for those reviews is one thing we always push our firms to do because, like you said, you look at those reviews to see if they're real or not. Most people look first at the newest reviews, the most recent review that was posted, and then they look at the lowest review. Those are the two categories that people care the most about. So, it's important for the firm to be involved just as much as the marketing company to make sure your reputation is good too.   Sharon:          Do you explain that from the very beginning, that they have to be involved?   Stephanie:    Yes, and we will only work with firms that will be involved. We're very lucky that we're exclusive, so we only work with one firm per practice area per geographic location. If a firm isn't a partner with us, there's only so much we can do for them. But having that partnership, we are the best in what do. We like working with the best firms. It creates the best partnership for everybody's success. But yes, it's very important that they're also a part of their own success up front.   Sharon:          When you say success, is that lead generation? Is it just what they're doing?   Stephanie:    Yes, lead generation. Our goal is to help firms become visible online organically. Our main focus is search engine optimization, which is organic placement on search engines. We do paid ads, and we're very good at doing paid ads as well, but it's that organic placement that you get the most return from. The more rankings these firms have on the search engines, the more phone calls they're going to get and then hopefully the more cases they get. It really does work that way. We can track a ranking on the search engines, and then we track their phone and work with them to hear how many cases they're getting, and it really does work in that direction.   Sharon:          Social media and the paid stuff aside, do you encourage lawyers to write articles? Does this help?   Stephanie:    With our clients, we handle all of the writing because there are couple of different ways you have to write. Number one, you have to write to make sure you're the voice of the firm and it makes sense. You're writing about cases you're looking to get, but you also have to make sure you're writing so the search engines can recognize you. For instance, a very popular search phrase right now is “near me,” like “car accident attorney near me,” “car accident lawyer near me,” “dentist near me,” “best optometrist near me.” It's making sure you get those “near me” keywords in your content, making sure your content includes questions and answers, because a lot of people are asking questions of the search engines.   We do have firms that like to write themselves. Attorneys are wonderful writers, but if they're not writing so the search engines can recognize what they're saying, it's not going to help them become more visible when it comes to these search phrases. It's a balance. We do all the writing for our clients with their approval, but if somebody does want to write here and there, we encourage that. We would just help with massaging the SEO and the content.   Sharon:          Would you massage the SEO or the stuff that makes them go higher in the rankings? If they have a website already, would you say, “It's wonderful, but we can go in and do some things”? What do you do?   Stephanie:    99% of the time, we rebuild and redesign and develop the website first. The reason we do that is because a lot of how your website is built is how you're going to perform on the search engines. For instance, if you have a very slow website, Google does not like that. Your site speed is a factor if you're going to rank or not. So, we like to go in and clean up the website so we have a good product to work with to then help with SEO. From there, we write content, build out the content, create site maps, really get to know the firm, their voice, and figure out the types of cases they're looking for. Then we write content around that to help them rank on the search engines.   Sharon:          Are you called in when they say, “We're about to embark on a rebuild of our website”? It seems to me they already have one when they call you in.   Stephanie:    Sometimes that happens, where we start working with a firm and they just rebuilt their website, and we have to give them the bad news of “I'm really sorry, but this website isn't going to perform.” We wouldn't take on that client because we want to set up the proper expectations of success for our clients. If you have a marketing company tell you, “Oh no, that's O.K. Your website's slow, but we could still work with it,” that would be a red flag because it won't work as well as it could if you redid the site. It happens sometimes.   Sharon:          Going back to the “near me,” I don't even enter that, but that comes up as a choice to click on.   Stephanie:    Yeah, that's usually right.   Sharon:          That's interesting. What do you mean by content writing? Is that what you mean when you're making sure the content—   Stephanie:    When it comes to content, you have the content pages on the website. Some of the most popular content pages on a law firm's website would be their practice area pages. You might have a page on wrongful death. You might have a page on car accidents. You might have a page on personal injury. Then each one of those pages includes content. The type of content on that page could be question and answer, could be including those words “near me.”   Google pulls from that content to determine how you're going to rank based on the way the person is searching. You'll see a lot of times where Google does an instant answer. If they're asking a question, “what is the statute of limitations in the state of California for a wrongful death case,” a law firm's content page could answer that question, so they'll bring it up as the first result.   There's also blogging. You want to make sure you're blogging on a regular basis. In the past, it was as much content as you could put on there. The phrase “content is king” is gone. That used to be the way we spoke when you would push content, push content, push content. Now, it's more about the quality of content versus the quantity of content. It's making sure it's good content that's enriched with the types of cases you're looking for, and written well so the search engines recognize you as an expert on that topic with experience and expertise in the discussion. Google will see that and help you rank better based on the content and what you're saying.   Sharon:          Is that per lawyer? Let's say on the home page of the website you have banners or badges that say, “We're the best.” Or is it in the bio?   Stephanie:    It would be in a practice area page. When somebody does a search for a car accident lawyer, let's say, Google wants to provide them with the most specific information they're looking for. So, they'll more likely pull up a car accident page from your website and show that over your home page. Your home page should be a summary of everything you do, and then the content pages are more specific on each practice area. When somebody does find you, they're going to find that practice page usually over your home page, but all of your content should include things that are easily identifiable for Google.   Sharon:          I always laugh when I see a bio that says they specialize in 20 different things, because how many can you specialize in? What would you do? Would you put everything the firm does? What would you do in order to come up?   Stephanie:    With a bio, you really want to focus on that attorney and what they've done and that's it. When it comes to the actual practice area pages, that's where you would focus on that practice area. Then maybe you could put in a little sentence or two about which attorney does that, if that makes sense. There are ways of doing it. It's not necessarily a right answer or a wrong answer. It depends on the firm, the market, the practice area. But there are ways you can incorporate that being specific to the attorney and what their expertise is versus what the whole firm does on the bio page, if that makes sense.   Sharon:          It does make sense. Should you put successes like, “We won a case that was really hard to win for $10,000 and John Smith did it”?   Stephanie:    Oh yeah, verdicts and settlements pages and verdicts and settlements in general are some of the most visited areas on the websites. People want to see numbers. There are some markets where they might not be allowed to put verdict and settlement numbers on their website, or the firm doesn't feel like it's appropriate to do that. But by the way, law firms that put their numbers on their websites get more attraction than the ones that don't.   Sharon:          The big question is do people choose a personal injury firm because they like the lawyer? It's a nice, touchy-feely firm versus one that's won all of these big numbers but they might not like as much. How do you choose? What's more important?   Stephanie:    That's a good question. Again, it comes back to the person choosing and what's important to them on why they're choosing, but if you don't have the big numbers, you definitely want to talk about what you've done. A lot of people want to feel that they can relate to that attorney. I always say talk as much as you can about things you've done to help other people. If I had a case that was specific and I read that that attorney has helped other people with the same thing I have, I'm more likely to work with them regardless of what the numbers are because I feel like they could help me. If you don't have those big numbers, you want to discuss what you've done because people will be able to relate to that.   We're also big believers in putting personal information into those bios. Talk about your hobbies, talk about your children, because people relate to things. There are so many situations where I've heard that this attorney got a case because somebody saw they had the same hobby, they went rafting or whatever it was, and their son had passed away, or that they were calling him because he had the same alma mater. Obviously that is a big one people gravitate toward. Outside of politics—I would stay away from writing anything related to politics—the more information you can humanize yourself with, it's going to help people connect with you better and they'll end up hiring you.   Sharon:          That's interesting. I've heard that both ways. I tend to relate to people, so I would like to know more about them. That's interesting that you should put it in your bio. Are you usually called in the beginning or are they already underway? Why are you called in? Tell us about your business. That's several questions, sorry.   Stephanie:    That's O.K. Usually we're called in when a firm is looking to take their law firm to that next step and they're looking for more cases. They're not showing up online. They're not getting phone calls. They're not getting cases online. A lot of times, we're called in to firms that have worked with referrals for pretty much their whole law career. They're always getting referrals, and they're tired of paying those referral fees to other attorneys. They'd like to generate cases themselves from the internet. Then we would be brought in to help them analyze what's going on in their market and what their current web presence is. Then we can put together a plan to get them to where they need to be to generate more calls that generate the cases they're looking for. It's usually somebody that wants to make more money off the internet in some way, like they're tired of paying referral fees and/or they're looking for more visibility and better-quality cases. We hear that a lot; that we help firms create better-quality cases over anything else.   Sharon:          Better quality meaning larger cases, bigger numbers?   Stephanie:    It could be anything. It could be that it's a firm that did a bunch of slip and fall cases and now they're getting bigger and better quality personal injury cases. It's medical malpractice firms that used to get a lot of junk calls and now they're getting quality calls, things like that. We're really good at SEO, and we're really good at creating more rankings for somebody organically. Usually when somebody finds a firm organically, they tend to be better qualified, quality leads.   Sharon:          Do you keep your eye on the changes in the Google algorithm?   Stephanie:    Yeah, we have a SEO specialist that works with digital marketing. We're all senior level, too. I always like to mention that because our SEO specialists are also very recognized in their SEO space. We have one Google Product Expert that works for us. She's one of 50 in the world. She's outstanding. We also have a Google Local Search expert who's been nationally recognized. They're the ones that keep up with the trends and how things are changing, and then we push that down to all of our firms. We're constantly moving in different directions with content and with SEO strategies based on the changes in the Google algorithm and changes in how we as human beings search. It is ever-changing. If you looked back 10 years ago from today, it's totally different to what we're doing. Even a year ago, it's a different strategy than what we were doing.   Sharon:          That sort of leads me to the next question. When I search, you have to skip like 10 sponsored ads. Is it possible to be high organically?   Stephanie:    Absolutely. It's interesting because Google has put a lot of emphasis on their paid ads. They have a newer ad called the Local Services Ad. It's been around for two years now, but those are the ones where there are pictures at the top of the page. They're considered Google screened, but they're driven by reviews and making sure that somebody answers the phone and other things in your budget. But the biggest driver of those is how frequently you're getting reviews, which is interesting that Google is doing that. So, there are different types of advertising they're doing, and they're pulling in an organic element with those reviews. Below that you have your pay-per-click, which is the paid advertising for Google Ad Words, and then you have your local. But yes, local SEO is still the sweet spot of getting calls. The firms we see, the majority of the calls come in through that local SEO space.   Sharon:          When you say you only take one practice area and one geographic area, do you have a map divided up? What do you call a geographic area?   Stephanie:    It depends on the marketplace, but a lot of it has to do with where the office is located. For instance, we have a state where the firm has 10 office locations throughout the state. Well, they're the only personal injury firm in that state because they have so many offices, so we're not going to work with anybody else. It comes down to who their competitors are. Our whole thing is we're not going to work with your competition. If it's too close for comfort, we go to our clients first and have them tell us if it's O.K. if we work with them, yes or no based on the competition, and we will or we won't. We do not cross that line at all. We are 100% exclusive, and that's why. We only have a handful of clients per state because it's all we want. We don't want to be the biggest SEO company out there. We want to be the best, and we feel that we are.   Sharon:          What do you do if you're in a room of lawyers, whether it's partners or not, and they say, “Reviews aren't a problem. Sally in marketing handles the reviews”? What do you do then?   Stephanie:    It depends. Maybe Sally in marketing really does do a great job and she is getting multiple reviews a week. That would be awesome. We wouldn't have a problem with that at all. But if Sally in marketing hasn't gotten a review for six months, we can see that. We can say, “Oh, that's great, but the best thing for firms is to get consistent reviews on a regular basis. Two to three reviews a week would be ideal.” We can show that they're responding to them, that they're engaging with that list, and we really push that.   We've had situations where we have gotten firms top ranked—I keep trying to say first page, but there are no pages anymore when it comes to Google. It's about rank. You can't even scroll. So, we could get somebody at the top of the rank of the search engine, but if their reviews aren't good, nobody's going to call them. We've done our job, but nobody's going to call you if your reviews aren't good. It's a two-way street. We coach our firms. We encourage them. We do a lot with intake. We can audit phone calls and help them figure out how people are handling their calls. It's a lot of coaching and encouraging and trying to do our best to get them to do their part, too.   Sharon:          I think you just preempted my next question. You can have wonderful numbers, but if they fill out the intake form and nobody sees it—   Stephanie:    Yeah, if they're not answering the phone. We see this a lot. We'll do audits with some of the most successful firms in lots of different situations. I'll never forget there was a catastrophic injury/medical malpractice firm, and a lady called very upset saying that her daughter was just diagnosed with cerebral palsy, and the woman's like, “I don't know if we do that. Hold on. Let me check. Yeah, we do that.” Now the confidence is shot. There's no way. These are not the people to hire.   Intake is such a big part of these firms. It's probably the most important part that our lawyers aren't paying attention to right now. Not all our firms, but in our industry in general. We're doing a lot with our clients to help them with that, but in our industry as a whole, I feel like intake is probably the area that can be improved the most.   Sharon:          People don't talk about that enough, I think. They talk about how much money everybody is spending on SEO and organic, but not about when the calls come in, where they were sent or what happens. Stephanie:    It's really a salesperson on that line if you think about it. As you said, firms are spending thousands and thousands, tens of thousands of dollars a month in marketing, but who's answering that phone? All your dollars are going out the window when you don't have the right person. They usually want to cut costs on those types of positions, when really it should be handled as a sales organization. Some of the more sophisticated PI firms, those large firms that are coming into different markets, are handling those as sales calls. It's changing. I've seen firms do a great job, but I do think that's one of the first things that is overlooked. Hopefully it's coming to light now. More firms are starting to do better at it, but you've got to take care of all the parts.   Sharon:          There are a lot of parts. I was laughing when you said content is king because that's what people used to say. There was a time, a long time ago, when you could tell somebody, “Just write a lot about what you do and you'll be O.K.,” but that's long gone.   Stephanie:    Yeah, it's gone now.   Sharon:          Would you say that a website is the hub of everything a person is doing when they're doing paid ads and SEO?   Stephanie:    I probably would have used to say that, but what I would say now is if you do a search for the firm's name on Google, that is the new homepage. Whatever you see that comes up there is what I would be more concerned about than even the homepage of your website. The reason I say that is because if you do a search—let's say you're a car accident lawyer and somebody finds you by doing a search for car accident lawyers. They are going to see your presence on Google pop up first. Sometimes they'll go directly to your website; sometimes they'll look at your reviews before even looking at your website; sometimes they'll look at where you are before doing that. There's a lot of information they can find out before even getting to your website.   If somebody does a Google search of your firm name, on the right-hand side of that search is usually where you'll see the Google information and Google reviews, but on the left-hand side is all those other directories out there, which could have bad reviews. That shows up before somebody even gets to your homepage. It used to be that your website is the hub of everything. It's still incredibly important, and maybe it still is the hub, but when it comes to your reputation, you really need to see what Google has on your firm. What is your brand telling people before they even get to your website? What are all these directories saying? What are all these reviews saying about you?   Sharon:          What are you seeing with all the sponsored ads? I just happened to look at your website, and there are about five sponsored ads before you even get to yours. What do you do? Is that part of it?   Stephanie:    If you were to google Digital Law Marketing, there are other law marketing companies that will bid on our name to show up ahead of us. That happens. Or somebody could be bidding on digital marketing or terms like that, but people can see that they're sponsored or paid ads. You can see that right there. Most people, if they're looking for the real website, will pass those and go directly to the organic.   Now, some people search differently. Some people would click on the first one they see, but users are becoming a lot more sophisticated than they ever have been, so they understand what an ad is. Sometimes ads are the best result. Google has also done a good job with the ad program so that sometimes the best information you're finding is in the ads. It depends, but it's hard to get away from those ads. One thing you could do as a business is bid on your name. For instance, we bid on Digital Law Marketing, so we're one of the first that pops up when somebody does type in our name. But you do want to make sure you're aware of what is on the internet about your brand.   Sharon:          It seems like the world has changed so much as a marketing person who's interested in everything you're talking about. For the firm to be at the top and on social media and everywhere, you need a bunch of experts. They need their own team. You can't be an expert in everything or just a lawyer who's interested in marketing.   Stephanie:    You're absolutely right. We touch on social media, but there's so much more you could be doing with social media. There are so many different avenues and elements of everything. You could have, like you said, a whole team. You hire a company like ours to manage the website, the SEO, the paid ads. Then you have somebody that does social media video, optimization and things of that nature. Then you get somebody that just does PR. PR companies and SEO companies work really well together because it creates good results when they do. There are so many different things. It's not just hiring one person and they can do everything.   Sharon:          But the marketing person or the lawyer who's interested should also be auditing calls or at least know what's happening.   Stephanie:    Yeah, and there are so many different tools now. We use something called dynamic call tracking where you can record every call. We're constantly spot checking and listening to our clients' calls to make sure the leads are being handled properly once we bring them to the law firm. If they don't, they're not going to see the success of their marketing dollars.   Sharon:          Have you ever had to make changes because of the dynamic call tracking?   Stephanie:    Yeah, we've had to. We've actually had to not renew agreements with clients. In almost 10 years with Digital Law Marketing, we've only lost a handful of clients, and two of those we actually let go ourselves. The reason we let them go is because they weren't helping themselves and they weren't helping to be a partner. At the end of the day, nobody would be successful. Lots of times we have these hard conversations with firms and say, “O.K., this what we found out. We did an audit and 40% of the calls aren't being answered.” The firms are very receptive to it, and they make changes quickly. That's why they hire us, because they know we'll help them with making those decisions. We've had lots of hard conversations with firms, but if firms aren't willing to help themselves, it's hard for us to help them.   Sharon:          I presume you've been in the position where you've come in to replace another SEO firm.   Stephanie:    Oh, yeah.   Sharon:          How long should a law firm wait to see results?   Stephanie:    Good question. We ask all of our clients at Digital Law Marketing to give us one year of SEO. After that, it's month to month. We don't renew clients because if you don't want to be with us after a year, then we're probably not the right fit. But we don't lose clients because we can show you within a year what we've been able to do for you. If it's not us, then try somebody else. I would definitely give it a year.   Just yesterday, I had a call from somebody who was frustrated because their marketing company had been working for three months and the results weren't showing up. I'm like, “You really need to give them longer than three months. Give them a good year. I'm not going to say you're going to be at the height of your performance in a year, not at all, but you will see progression.” We tell people all the time, “We'll be able to show you in the first 90 to 120 days how you're ranking better, how you're getting more phone calls.” We continually show that progression because it takes years to get really good visibility on search engines. You're telling Google who you are over a long, consecutive period of time of building your brand, but you will see progression quickly. You're just not going to see ultimate results for some time.   Sharon:          You must have lot of people say, “A whole year? You want me to wait a whole year before I start to evaluate?”   Stephanie:    People have figured it out now. It used to be more of a challenge five years ago, but people have figured it out. SEO takes a while. With paid ads you can see a return a little quicker, but it's still not as quick as it used to be. With paid advertising, we tell everybody to give it at least three to four months. There are so many people that are doing paid advertising, so it takes a little longer. It used to be that you were able to see results in a day, but it's different the way things are working now. It just takes time, but if you're consistent and you're doing the right thing over a consistent period of time, you will see the right results with the right company. You have to make sure you trust who you're working with, too.   Sharon:          That's probably a big factor. One of the last questions, if you can tell us, is about how people find you. Do they only find you because of a web search, or do they find you other ways? How do they find you?   Stephanie:    The law firm?   Sharon:          Yeah, how do your clients find you, so they call you versus another company?   Stephanie:    They could do a web search and find us that way. We are Diamond Sponsors of the American Association for Justice, the AAJ. It's a national organization. We're also sponsors of the National Trial Lawyers. We do travel a couple of times a year to conventions and meet new firms. A lot of our clients come from other clients because our clients tell our story a lot better than anybody else. On our website, we have a bunch of FAQs and testimonials from our clients, but they can look us up on Google, social media and through our website.   We have a form on there so we can do free SEO audits for firms. We'd love for them to fill that out and see if it's something we can help firms with. We are working with firms all over the country, but we do have markets available, so we'd love to hear from anybody that's interested in not having to hire a company again. A lot of times, people come to us and say, “I'm tired of switching companies every year or every two years.” Our clients don't have to do that anymore. So, come to us and you don't have to continually look further.   Sharon:          That's a big point of differentiation. For everybody listening, we'll make sure to have the website link and any other links. Thank you so much. We really appreciate it, Stephanie.   Stephanie:    Thank you for having me, Sharon. It was fun.   Sharon:          Thanks. Stephanie:    Take care.

Joël submitted a last-minute submission to RailsConf discreet math, which got picked up!

Today's episode is "Old News"! Stephanie shares her ergonomic desk setup. Joël talks about the pyramids. Another old thing is the Bike Shed episode two weeks ago about success and fulfillment. Stephanie and Joël realized off-mic that one area they didn't really talk about so much is impact, and that is something that is very fulfilling for both of them. Today, they talk about impact and leadership as individual contributors because leadership is typically associated with management. But they believe that as ICs, at any level, you can be displaying attributes of leadership and show up in that way on teams. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Success and Fulfillment episode (https://www.bikeshed.fm/376) Logitech MX Vertical (https://www.bestbuy.com/site/logitech-mx-vertical-advanced-wireless-optical-mouse-with-ergonomic-design-graphite/6282602.p?skuId=6282602&ref=212&loc=1&extStoreId=319&ref=212&loc=1&&&gclid=EAIaIQobChMItMP27PT8_QIVfMiUCR0_dwVqEAQYASABEgIWJ_D_BwE&gclsrc=aw.ds) Rose Wiegley's Lead From Where You Are (https://www.youtube.com/watch?v=1GorXHiB7nw) 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 old in your world? STEPHANIE: I'm glad you asked that question because I don't think we get a chance to talk about things that are exactly the same as they've always been. And so today, I'd like to share my ergonomic desk setup, [laughs] which has been old for about a year or so. And back then, I was having some issues with some back pain and some wrist pain, and I made a few upgrades and since then have not had any issues. And I feel like it's one of those things that I just forgot about because when it stops being a problem, you don't really notice it. And today, I am able to reflect on my old problem of bodily pain while working. And I'm happy to say that things have been much better for a while now. JOËL: Oh, that's amazing. What's one thing you think had the most impact in your setup? STEPHANIE: Oh, I picked up one of those vertical mice for my wrist. I was having some wrist pain, like I mentioned. And I actually solicited some input from other thoughtboters for the best mouse to replace the Apple Magic Mouse that I was using, which I really wanted it to work for me because I liked the way it looked, but nevertheless, that was causing me issues. So I ended up with the Logitech MX vertical, and that has really solved my wrist pain. It is very not cute. [laughs] It kind of looks like a weird big, gray snail. But you know what? You got to do what you got to do. JOËL: That sounds like an art project waiting to happen. STEPHANIE: Yeah. I would love to see; I don't know, a way to make these vertical mice look a little more cute. Maybe I will stick some googly eyes or something on it and then just be like, this is my pet snail [laughs] that works with me every day. JOËL: Do you have a name? STEPHANIE: Not yet. Maybe I'll save it for what's new next week. [laughter] JOËL: Homework assignment. Years ago, I was also having some wrist pain. And I think one of the most impactful things I did was remapping some keys on my keyboard. So I'm a pretty heavy Vim user. And I think just reaching with that pinky for the Escape key all the time was putting a lot of strain on my wrist. So I remapped Caps Lock to control. That's what I did. Yes, because it was reaching down with the pinky for the Control key and remapped escape to hitting J twice. So now I can do those two very common things, Control for some kind of common chord and then Escape because you're always dropping in and out of modes, all from the Home row. And now, both my hands feel great, and I can be happy writing Vim. STEPHANIE: That's really nice. I think when I had asked in Slack about mouse recommendations, someone had trolled me a little bit and said that if I just use my keyboard for everything, then I won't need to use [laughs] a mouse at all. [laughs] So there's also that option too for listeners out there. JOËL: It's true. You go to tmux and Vim, and on a Mac, maybe something like Alfred and a few OS shortcuts, and you can get 90% of the way to keyboard only. STEPHANIE: What about you, Joël? What's old in your world? JOËL: So you know what, something that's really old? Pyramids. STEPHANIE: Wow. [laughter] I should have known that this is where we were headed. JOËL: Long-term listeners of the show will know I'm a huge history nerd. And we think of the pyramids as being old, but they are ridiculously old. A fun fact that I have not learned recently because this is something that is old in my world, but that I learned a while back is that if we look back to Cleopatra, the last Pharaoh, she is closer to us in time than she was to the building of the Great Pyramid. STEPHANIE: No. What? Wow. Okay, yeah, that definitely just messed with my brain a little bit. And now, I have to rethink my understanding of time. JOËL: I think the way the timeline sort of works in my mind is it tends to get compressed the further back you go. So it's like, yeah, I think of modern-ish times, like, yeah, there's like a lot of stuff, and I'm thinking in terms of decades until maybe like the 1900s. And now I start to think in terms of centuries. And they're kind of more or less equivalent, you know, the Victorian Age. It fills about the same amount of space in my mind as like the '60s. And then you get to the point where it's just like millennia. STEPHANIE: Mm-hmm. When you think of Ancient Egypt, do you think Cleopatra and also pyramids, so you kind of conflate? At least I do. I conflate the two a little bit. But yeah, I guess a lot of time passed in between that. [laughs] JOËL: The pyramids are also really cool because they were one of The Seven Wonders of the ancient world, which is sort of, I want to say, like a tourist circuit created by the ancient Greeks, sort of like monuments that they thought were particularly impressive. But they're also the only ones that are still standing; all of the others have been lost to time. STEPHANIE: Wow, it's the real wonder then [laughs] for being able to stand the test of time. JOËL: It's also the oldest of the seven and has managed to survive until today, so very impressive. STEPHANIE: I love that. Just now, when you were talking about thinking about time periods kind of compressed, I definitely fall victim to thinking that the '70s or whatever was just 30 years ago, even though we are solidly in the 2020s and, in reality, it's obviously like 50. But yeah, I think that always freaks me out a little bit. JOËL: Yes, it's no longer the year 2000. STEPHANIE: Turns out. [laughs] So, in case our listeners didn't know. [laughs] JOËL: I think when we were close-ish to the turn of the millennium, it just made mental math so easy because you're at that nice zero point. And then you get to the early 2010s, and it's close enough within a rounding error. And now we just can't pretend about that anymore. STEPHANIE: No, we really can't. JOËL: We need a new anchor point to do that mental math. STEPHANIE: I love that we're talking about what's old in our world because I love a chance to just repeat something that I've said before that I still think is really cool, but I feel like that doesn't get invited as frequently. It's just like, oh, how are you doing? What's new? So yeah, highly recommend asking people what's old in their world? JOËL: Yeah. And beyond that, not just like, what are some new things you're trying? But kind of like what you were talking about earlier, what's something that's stayed stable in your life, something that you've been doing for a while that works for you? STEPHANIE: Yeah, I love it. So another thing that's old is our episode from a couple of weeks ago about success and fulfillment. And you and I realized off-mic that one area we didn't really talk about so much is impact, and that being something that is very fulfilling for both of us. And that kind of got me thinking about impact and leadership. And I especially am interested in this topic as individual contributors because I think that leadership is typically associated with management. But I really believe that as ICs, at any level, really, you can be displaying attributes of leadership and showing up in that way on teams. JOËL: Definitely. I think you can have an impact at every level of the career ladder, not just an impact on a project but an impact on other people. I remember the first internship I did. I was maybe two weeks in, and I had a brand new intern join. It's day two, and I'm already pairing with him and being like, "Hey, I barely know anything about Rails. But if you want help with understanding instance variables, that's the one thing I know, and I can help you." STEPHANIE: Yeah, that's awesome. I mean, everyone knows something that another person doesn't. And just having that mindset of injecting leadership into things that you do at work, no matter how big or how small, I think is really important. JOËL: I think there's maybe a lie that we tell ourselves, which is that we need to wait to be an expert before we can help other people. STEPHANIE: Yeah, I've certainly fallen into that trap a little bit where I think it's held me back from sharing something because I assumed that the other person would know already or the thing I'm thinking is something I learned but not necessarily something that someone else would find interesting or new. JOËL: Right. Or even somebody's looking for help, and you feel like maybe you're not qualified to help on that problem, even though you probably are. STEPHANIE: One thing that I was really curious about is, can you remember a time when an IC on your team demonstrated leadership, and you were really impressed by it? Like, you thought, like, wow, that was really great leadership on their part, and I'm really glad that they did that. JOËL: Yeah. So I think one way that I really appreciate seeing leadership demonstrated is in client communication. Typically, the teams we have at thoughtbot are structured on a particular project where there's like a team lead who is in charge of the project. It's usually a couple of consultants working together as peers. Depending on the situation, one or the other might take leadership where it's necessary. But I've really appreciated situations where a colleague will just really knock it out of the park with some communication with the client or when they are maybe helping talk through a difficult situation. Or maybe even we realize that there's a risk coming down the pipeline for the project and raising it early and making sure that we de-risk that properly. Those are all things that I really appreciate seeing. STEPHANIE: Yeah. I think the way folks engage in channels of communication can have a really big impact. A few things that come to mind for me that I think is really great leadership is when more experienced or senior folks ask questions in public spaces because that kind of cultivates a space where asking questions is okay, and even people who have whatever title or whatever years of experience they still have questions and can signal to other folks in the team that this is okay to do. And the same thing goes for sharing mistakes as well. Also, just signaling that, like, yeah, we mess up, and that's totally normal and okay. And the consequences aren't so scary that people feel a lot of pressure not to make mistakes or share when they happen. JOËL: Yeah. The concept you're describing is very similar to the idea of vulnerability. STEPHANIE: Yeah, that sounds right. JOËL: So kind of modeling that from more senior people helps create a safer environment for the more junior people. STEPHANIE: I think another thing that I really love that others do for me, and something that I want to get better at doing for others, is speaking up when something is a little off because, again, with power dynamics, for people who are newer or less experienced, they might be noticing things, but they don't feel encouraged to speak up about it in a public space or even with their manager. But they might confide in another IC who is maybe a little more senior. And one thing that I really liked that happened on my client project recently is a senior engineer said in Slack, "Hey, I noticed some sentiment from our daily sync meeting that we're cutting it close to our deadline." And he asked like, "Should we shift some priorities around? Or what is more important to make sure that we focus on in the next few weeks before the end of the quarter?" And I was just really glad he said that because I certainly had been feeling it. But I don't know if I necessarily kept a pulse that other people were also feeling it. And so having someone keeping an eye on those things and being receptive to hearing that from folks and then being like, okay, I want to make sure that I bring it up to the manager because it's important. I thought that was really cool. JOËL: Yeah. Now we're almost dialing into sort of emotional awareness of what other people on the team might be feeling and also the ability to think in terms of risks and being proactive about managing those. STEPHANIE: I like your use of the word risks because that definitely feels like something that, in general, people are scared to bring up. But ultimately, it is the signal of someone who is experienced enough to know that it's important to make transparent and then adjust accordingly. Even beyond noticing what folks are feeling, there are also more concrete things that can be noticed as well, like if team members are complaining about CI build time being really long and that being a repeating issue in getting their work done. Or any other development or tooling thing that is causing people issues, having someone notice how frequently that happens and then being like, hey, this is a problem. And here's what I think we should do about it. JOËL: So not only the awareness but also the initiative to try to enact change. STEPHANIE: Yeah, absolutely. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: So you and I are actually working on the same client but on different project teams. And you've been involved with making improvements to CI to reduce kind of the problem that I was just talking about where it takes a while for us to develop. And you are working on reducing the number of days between the master branch and when you are allowed to hit the merge button to make sure that feature branches had incorporated the latest changes for master. And one thing that I really like that you did was you solicited folks' input for what that time range should be. So I think you were playing around with the idea of giving people three days to merge, or else they'd have to rebase. JOËL: I thought it was being really comprehensive here with three days because, you know what? You solicited feedback, you got review, but maybe it's the end of the day, or maybe someone's in different time zones. So we definitely want to cover at least a 24-hour period. So three days gives you an extra day. It should be safe. Is there any common situation where you might want a PR to be open for more than three days, but you wouldn't have rebased the latest master changes? STEPHANIE: Yeah. I can see how you thought about it from a few different angles too. Like, you're thinking about time zones and folks working in other regions. And I ended up responding to you, and I was like, oh, what about the weekend? [laughs] JOËL: Oops. STEPHANIE: Because three days seems a little short if two of those days are eaten up by Saturday and Sunday. But what I liked was that you said, "Hey, I'm thinking about doing this. What do other people think?" Because you didn't claim to know what works best for everyone. And I think that's a really important skill to be honest, soliciting others for feedback, and knowing who to ask for and who to make sure you are not negatively affecting their work by making a change or making a decision. JOËL: And in this case, it helped me realize that I had skipped over the most obvious edge case while thinking I'd covered all the really niche ones STEPHANIE: We got there in the end, [laughs] and I think made the most informed decision. JOËL: I guess that's just good product design in general. Talk to your users, get early feedback, put a prototype out where necessary. You don't always want your users to dictate what you will do, but it's good to get their feedback. And similarly, I think that applies when working with dev-facing things; you want feedback from developers. If I asked everybody at the company, I would have gotten a lot of different answers. And I might not have gotten one that satisfied everybody. But having some of that feedback helps me make a more informed decision. STEPHANIE: Yeah, and to take it to the next step, I think there's also accountability for those decisions that you have to have. So if the decision that you made ends up being like a huge pain for some unforeseen reasons, I imagine you'd be on top of that as well and would want to figure out how to adjust if the experiment doesn't work as well as you would have liked. JOËL: Right. I think we often talk about failing early. In fact, we have a recent episode about dealing with failure. And we mostly talked about it from a technical perspective, catching errors or making code more resilient to failure. But there is also a human component of it, which is if you catch errors or design problems, and I'm using design here as a product design, not in visual design, at a prototype phase or maybe a user interview phase, you've saved yourself a lot of maybe unnecessary work that you would have had if you went out to the product phase and shipped it to your entire customer base. I guess, in a sense, it's worth thinking about other developers, the engineering team as customers sometimes. And a lot of the internal facing parts of your project are effectively a product geared towards them. They are the users. And so, throwing in a little bit of product development and design skills into building internally-facing software can have a huge impact. So beyond just thinking of developers as a sort of internal customer base, occasionally, we work on projects where you are building internal tooling for other teams; maybe it's business development, maybe it's the marketing team, maybe it's some form of customer support. And that can often have a really large level of impact. Have you ever been on a project like that? STEPHANIE: I have. One of my first jobs was for an e-commerce company. And I built tools for the customer support team for dealing with customers and getting their orders correct and fixed and whatnot. So I did work on an admin dashboard to make their jobs easier as well as the company also had its own internal software for dealing with warehouse logistics. And so, I also built a little bit of tooling for our logistics and fulfillment team. And I really liked that work a lot because I could just go over and talk to the folks internally and be like, "Hey, what did you mean by this?" Or like, "What do you want here, and what would make your life easier?" And I felt a much more tangible impact than I did sometimes working on customer-facing features because I would deliver, and that goes out in the world. And I don't get to see how it's being used, and the feedback loop is much longer. So I really liked working on the internal tooling. JOËL: In my experience, those teams are often really underserved when it comes to software. And so it's possible to make a huge impact on their quality of life with relatively little work. Sometimes you can just take an afternoon and eliminate a thing that's causing them to pull out their hair. STEPHANIE: Yeah, absolutely. And you get the satisfaction of knowing that you built something exactly as they wanted it. Whereas sometimes, with user or customer-facing features, we are guessing or experimenting a little bit. And yeah, I think having someone who then is very grateful for, I don't know, the button that you added that makes them have to click less buttons [laughs] when they do their work in an internal dashboard can feel really good. JOËL: Having that direct access can be really nice where you get to just go over and talk to them or shadow them for a day, see how their work happens, get to hear their frustrations real-time. It's often a smaller group as well than you would have for our customers, which might be thousands of people, and so you sample a few for user testing. But for an internal team, you can get them all in a Zoom call. I don't necessarily recommend doing a giant Zoom call for this kind of thing, but it's a small enough group that you could. STEPHANIE: I'd like to flip that around to you. Have you ever been on the receiving end of an improvement or someone else making your life a little easier, and if you could share what that was and how it made you feel? JOËL: I think pretty early on in my career, one of my first projects for thoughtbot, we were building a small kind of greenfield app for a startup. And another member on the team took a couple of hours one afternoon to just write a few small abstractions for the test suite that; just made it so much nicer to write tests. And we're pretty scrappy. We've got a tight deadline, and we're trying to iterate very quickly. But that quality of life difference was significant to the point I still remember this ten years later. I think we were rotating this developer off, and this was kind of a farewell present, so... STEPHANIE: That's really sweet. JOËL: You know what? I love that idea of saying when you rotate off a project, do a little something extra for the people you're leaving behind. STEPHANIE: Yeah, I love that too. It's your kind of like last chance to make a small impact in that world. JOËL: Especially because on your last couple days, you're probably not expected to pick up a ticket and get it halfway done. So as you're kind of ramping down, you might have a little bit of time to do some sort of refactoring task or something that needs to get done but hasn't been prioritized that will have a positive impact on the team. STEPHANIE: Yeah, or even writing a script to automate something that you have kind of developed the muscle memory for, like, oh, I run these three commands in succession. And if you could just wrap it up in a little script and hand it off to someone else, it is a very sweet parting gift as well. JOËL: Absolutely. So I'm curious, we opened the topic talking about impact, and you immediately connected that to leadership, and I want to explore that idea a little bit. Do you think impact has to be connected to leadership? Or are there ways to have impact, maybe outside of a leadership role? STEPHANIE: I think they kind of go hand in hand, don't you? Because if you are wanting to make an impact, then in some ways, you are demonstrating that you care about other people. And at least for me, that is kind of my definition of leadership is enabling other folks to do better work. And you and I talk about attending and speaking at conferences pretty frequently on the podcast. And that is a very clear way that you are making an impact on the community. But I also think that it is also a demonstration of leadership that you care enough about something that you want to share it with others and leave them with something that you've learned or something that you would like to see be done differently. JOËL: And just to be clear here, the way you're talking about leadership is not a title; it's an action that you do. You're demonstrating leadership, even if you don't have any form of leadership title. STEPHANIE: Yeah, absolutely. I think that because software development is a collaborative job, in some ways, in most things we do, there is some form of leadership component, even if you're not managing people or you don't have a particular title. JOËL: Like you said, it's about the things that you're doing to enable other people or to act as a sort of force multiplier on your team rather than how many people report to you in the org chart. STEPHANIE: Yeah, absolutely. JOËL: So if everybody aspires to enable each other and to be impactful, is it possible to have a team where every person on the team is a leader? STEPHANIE: Whoa, [laughs] asking the big questions, Joël. I mean, logically, the answer seems to be no based on our traditional understandings of leadership and being a leader or follower. But I also kind of disagree because, as developers, we have to make choices all of the time, and that can be at the level of the code that we write, the commit messages we write, what we communicate in our daily sync. And those are all opportunities, I think, to inject those skills that we're talking about. And so, yeah, everyone on the team is making decisions about their work. And inherently, to me, at least, the way you make those decisions and the impact of those decisions imply some form of leadership. What about you? What do you think about this? JOËL: It's tough because you can get into bikeshedding the definition. STEPHANIE: [laughs] JOËL: Which, hey, it's all about that, right? You know, is leadership about authority or decision-making capacity? Is it about impact? Is it about maybe even responsibility if things go wrong? Who's responsible for the consequences? It could be about position in the org tree and relative depth on that tree, to use some data structure terminology. But I liked your emphasis on the idea of impact and enabling others. So now it's a thing that you do. And so any member at any moment can be demonstrating leadership or acting in some leadership capacity, and they're contributing to the team in that way. And in the next moment, somebody else stands up and does the same thing. And it doesn't necessarily have to be in conflict. You can actually be in a beautiful harmony. STEPHANIE: Yeah, I really like the way you said that. I love a good beautiful harmony. [laughs] I think part of what has shaped my view on this is a keynote talk from RubyConf Mini back in November by Rose Wiegley. And her talk was called "Lead From Where You Are." And I think perhaps I've kind of internalized that a little bit to be like, oh yeah, everything we do, we can make a decision that can have a positive impact on others. So that has helped me at least feel like I have a lot more agency in what I do as a developer, even if I don't have the concrete responsibility of being a mentor to a particular person or having a direct report. It injects meaning into my work, and that goes back to the fulfillment piece that we were talking in, knowing that, like, okay, like, here's how I can make an impact. And that's all just wrapped up together. JOËL: So you kind of defined earlier the idea of leadership as work that has impact on others or that enables the work of others. And I think that there are some forms of that work which are kind of highly respected and will get you noticed and will be kind of called out as like, oh, you're performing leadership here. You stood up in that meeting, and you said the hard thing that needed to be said. And there are other forms of supporting or enabling the team that almost get viewed as the opposite of leadership that don't get recognized and are almost like you're seen as less of a leader if you're spending a lot of your time doing that. That can be sometimes more administrative work. How does that sort of fit into this model where we're talking about leadership as something that has an impact on others? STEPHANIE: Yeah, I'm glad you mentioned that because I have a lot of gripes [laughs] and thoughts, I suppose, about what work is visible and not visible and valued more or less. And I do think some more traditional signals of leadership, like talking the most in a meeting, like, that I don't necessarily think is my definition of leadership; in fact, the opposite. A true leader, in my opinion, is someone who makes space for others and makes sure that all voices are heard. And yeah, I guess it just speaks to like what I was saying about soliciting other people for feedback as well. It's like someone to me who demonstrates leadership is not someone who thinks that they have all the right answers but actively seeks out more information to invalidate what they think is right and find the right solution for the folks on their team. Similarly, in Rose's talk, she also mentions the idea of being a problem finder, so not just being tasked with solving a problem but looking around and being like, okay, like, what aren't we talking about and that we should be? And obviously, also contributing to making that better and not just being like, "Here's a bunch of problems, [laughs] and you have to deal with it," but that proactive work. Ideally, we are addressing those things before they become a huge problem. And I really liked that aspect of what leadership looks like as well. JOËL: Yeah, I think something that I've noticed that I do more as I've built more experience over time is that when I started off earlier in my career, it was a lot of here's a problem that needs to be solved, go and solve it. And then over time, it's what are the problems that need to be solved? You have to sort of figure out those problems before you go and solve them. And then sometimes it's even one level above that; what questions should we be asking so that we can find the problem so that we can solve them? And that will happen...it could be internally, so some of the things that I'm doing currently around improving the experience of a test suite is like, okay, we know sort of that it's slow in certain ways. How can we make that faster? We know that the experience is not great. But what are the actual problems that are happening here, the root causes? Or we're getting some complaints, but we don't really know what the underlying problem is. Let's go and search that out. STEPHANIE: Yeah, that brings to mind an issue that I think I see a lot on client projects where perhaps stakeholders or an engineering manager is seeing that we are slow to merge our PRs, and they kind of start reaching for solutions like, okay, well, people should spend more time doing code reviews or whatever, thinking that that's what the issue is. But in reality, maybe it's, I don't know, it can even be something as lower level as having to re-request reviews every single time you push a new commit because the GitHub settings are such that it requires additional approvals for every new change. And that is something that they would not know about unless someone spoke up and said, "Actually, this is what's causing us friction," and having to go back and do these manual tasks that maybe we should explore a different alternative to solve. JOËL: Yeah, instead of just jumping in with a solution of we need to throw more dev hours at this problem, it can be useful to step back and ask, okay, well, why do we have this problem in the first place? Is it a process issue that we have? Is there some sort of social element that we need to address and organizational problems? And if it's not that, then what are the questions that we're missing? What questions should we be asking here to understand this problem? STEPHANIE: Right. And even speaking up about it too and going against someone's assumption and saying, "Here's what I've been seeing, and this is what I think about it," that takes a lot of courage. And I do think it is something that is especially important for folks who are more experienced and have more responsibility or a higher-level title, but ideally is something that anyone could do. I would love to know for you, Joël, what is the most important way that you want to make an impact as a developer? JOËL: I think the human element is the most important. I want to have an impact on my colleagues, on the dev teams with my clients. I want to ship good work. But I think the most valuable thing to invest in is other people. STEPHANIE: Yeah, I agree. I think for me; it's like making a good work experience for the people that I work with. And it's also a little bit selfish because then that means I am having a good work experience, and I'm in a good culture and environment. But that is definitely an area that I spend a lot of time thinking about and wanting to start conversations about. JOËL: It's a win-win, right? You make it better for everybody else and better for you in the process. STEPHANIE: Exactly. JOËL: And it's okay for it to be somewhat selfishly motivated. Like, it doesn't have to always be every day super altruistic like; I just want to make the world a better place. STEPHANIE: [laughs] JOËL: Like, you know what? I want my corner of the world to be better, and in doing so, I'm going to make it better for everyone else. STEPHANIE: What's that phrase? The tide rising all the ships. [laughs] That is extremely not correct, but I think you know what I'm trying to say. JOËL: I think a rising tide lifts all boats. STEPHANIE: Yeah, something like that. I love a good rising tide. [laughs] On that note, shall we wrap up? JOËL: Let's wrap up. Or let's rise up. STEPHANIE: [laughs] STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

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

Innovation is risky business, especially if you’re a hardware startup. But it’s not just risky on the part of those inventing a new product. The early adopters of that product are putting a lot on the line, too. Which is why certain industries, like retail, have remained mostly the same for decades. Retailers only want to bring in something new if the operational cost of installing and using the innovation are minimal, and if it doesn’t require a massive overhaul of a retail space. This is exactly what Lindon Gao found out when he started exploring this space. Lindon has been on a mission to disrupt retail since his first application for a smart security tag was accepted by Y Combinator, and while that hardware didn’t take off, Lindon kept going until he landed on an idea that stuck. Today, Lindon is the CEO of Caper, a company bringing smart cart technology into the retail space with increasing success. In fact, Caper’s tech could be coming to a store near you, as the company recently agreed to partner with America’s largest grocery retailer, Kroger, to bring smart carts into chains all over the nation. On this episode of Up Next in Commerce, Lindon talks us through how Caper is finally bringing change into the world of grocery, and he explains how smart cart technology could have ripple effects on ecommerce, personalization, and the entire customer journey. Enjoy this episode!Main Takeaways:Where’s The Easy Button?: Implementing new technology isn’t easy in retail. The operational headaches of launching anything new often outweighs the benefit of most of the new tech being presented. Incorporating new tech as a retailer requires finding innovations that don’t need large system overhauls, already naturally fit into the customer’s store journey and provide an added benefit (i.e. more customer data, more opportunities to upsell, etc), to make the investment worth it. Do You Want a Receipt?: Smart receipts are one of the top ways to keep track of consumers after they make a purchase. Receipts offer a window into consumer behavior, and also provide a new area for personalization and follow-up conversations that keep customers engaged.It’s Not Either Or: When it comes to ecommerce and grocery, it is not an either/or question. Both in-store and online shopping will continue, and, in fact, the move toward ecommerce will only push the in-store experience to be even more efficient and streamlined.For an in-depth look at this episode, check out the full transcript below. Quotes have been edited for clarity and length.---Up Next in Commerce is brought to you by Salesforce Commerce Cloud. Respond quickly to changing customer needs with flexible Ecommerce connected to marketing, sales, and service. Deliver intelligent commerce experiences your customers can trust, across every channel. Together, we’re ready for what’s next in commerce. Learn more at salesforce.com/commerce---Transcript:Stephanie:Hey everyone, and welcome back to Up Next in Commerce. This is your host, Stephanie Postles, co-founder and CEO at Mission.org. Today, on the show, we're chatting with Lindon Gao, the CEO at CAPER. Lindon, welcome to the show.Lindon:Thanks for having me, Stephanie.Stephanie:Yeah. I'm really excited to have you on. So, tell me a bit about Caper. I was doing a little bit of background digging. And maybe, actually, it'd be great to start with your background first. I saw that you were involved with Y Combinator. So, maybe starting off there, and then we'll get to Caper.Lindon:Sure. I joined Y Combinator shortly after I left investment banking. So, prior to YC, I was an investment banker in Goldman Sachs and JP Morgan, have had quite a number of corporate lives, and didn't really feel like I belonged in finance as much as I belong in startups. I started my first startup when I was 14, my second one when I was 19. So, I've always had a lot of passion for the startup industry. And when I realized that there was a big opportunity to potentially pursue in physical retail, I decided to quit my job to start Caper. And we were lucky enough that we got into YC. And our first application, I remember at the time, we-Stephanie:That's lucky.Lindon:Yeah. And we built... At the time, we were actually building a different product. We built a smart security tag. You know those that beeps at the door if you try to steel in Zara? We made it such that it will unlock upon payment. So, just imagine, on Black Friday, you could walk into a store. You could take out your phone, tap on that security tag, pay for it, and the security pack will unlock, and then you can leave the store.Stephanie:Smart.Lindon:Yeah, so...Stephanie:What happened with that? I still need that?Lindon:I could get into that a little bit actually. So, we built a prototype for the smart security tag. And then, onsite during the YC interview... YC interviews are ten minutes. So basically, within 10 minutes, you have to knock out everything. And they will be firing questions at you. They will be cutting you off during the interview. I've thought about something that was very interesting. Since we only had 10 minutes, I wanted to convey industry urgency, our market. So, I printed these t-shirts where it says, "Did you know that customers will leave the store if they have to wait in line for more than five minutes?" 33% of customers will leave.Lindon:So, I printed it out on a t-shirt. And I walked in. And all of a sudden, the interviewer is... At the time, it was... I remember it was Geoff, Geoff Ralston, who is the president of YC. He looked at it and it was, "Oh. Interesting t-shirt." And we started talking. And I remember, at the time, our prototype was working 50% of the times. So, when we did the demo, the prototype... We were hoping that it will unlock. So, we're praying, praying, praying. And it did. So, if it didn't-Stephanie:Whew.Lindon:Yeah. So, if it didn't unlock, I think I would probably go back to finance and be an investment banker by now, but luckily it did. So, we got to YC. We build the security tag out. We signed on a couple of really, really large apparel customers. And we launched with Rebecca Minkoff in Soho. But we realized that the tech was really difficult to scale, because you need to apply the technology onto every single garment. That means that it was a gigantic operational overhaul. Every week, the store stock needs to maintain it somehow to make sure that all the new inventory that comes in are tagged, and are synced, with the specific unique identifier for each garment. And that just proved to be too much.Lindon:And so, we built it for about a year and a half before we realized that we were just being stubborn, and it was too difficult to scale to market. And that's when we decided to pivot.Stephanie:Very cool. So, what happened next after that? Is that when you... Had you already been thinking about a smart checkout grocery option. Or did you all have to huddle and start brainstorming to be like, "What's next? Where are we going to go now?"Lindon:It was very difficult at the time, because we were not a typical YC company, in that we are a small portion of the hardware companies in YC. And hardware companies are not very popular. So, when we-Stephanie:They're expensive.Lindon:Exactly. It's very capital intensive. Investors don't like to invest in it. So, after we did our demo day, we didn't raise so much money. We raised like two, three hundred K, in total. Typically, YC companies, they come out, they sign a million dollar term sheet on the demo day. And there I was, after demo day, some of my buddies were signing term sheets left and right. I was just like, "Hey. You guys want to chat?" And they were like, "Ah. You guys go hardware, not really."Lindon:So, throughout the whole time, it was very difficult. So, when we built it, built a security tag for about a year and a half, none of us were getting paid. At the time, it was four co-founders and two early employees. We lived and worked out of a house in College Point in New York. It's right by the LaGuardia Airport. And yeah, all we did was just we woke up. We worked. We'd eat together, and work, and we'd go to sleep.Stephanie:I heard you got in trouble for buying orange juice [crosstalk].Lindon:Where did you hear about that? Yes, I did.Stephanie:I just did a little creeping on the internet.Lindon:It was a very funny story. My co-founders are extremely frugal because we really didn't have too much money. We were bringing $7,000 per month. And we'd buy groceries together. I'll walk into a grocery store... It was a habit. I usually drink orange juice. And I dropped it in. My co-founder's like, "Do you really need to drink this? This is like six bucks." I'm like, "All right. Maybe you're right. I don't."Stephanie:Oh my gosh.Lindon:So, it was pretty tough. But it was also very interesting in that the passion really bonded us together. And that's why our team is extremely cohesive, even today. We barely have any attrition in the company. And our team is like a family. So... yeah. So, we built a security tag for a year and a half. And at the time, when we decided to pivot, we had probably less than probably 100K or something left in the bank. So, we really didn't have too much money, and we couldn't do too much with that amount of capital, especially in a hardware.Lindon:So, we kind of huddled together and we were thinking about what sorts of things should we pursue next. Or should we just kind of close up, just go home, and start applying for other jobs? And we decided that it was the retail, the grocery, just general physical retail industry has been extremely under innovated over the past decades. If you were to walk into a grocery store after world war two versus today, it will essentially be this... It's basically the same.Lindon:And we just couldn't understand retailers are not innovating. So, me and my co-founder, Ahmed, took a slightly more drastic approach in that we're saying, "Hey. You know what? Before we decide on building anything, let's go out to the market, and let's talk to grocery store owners." But before we went to the market, we were brainstorming. What are some of the things that we could do with our capability? So, we thought maybe... If we retrofit the entire store with sensors and cameras, maybe we can enable a check out free experience [inaudible] retail stores.Lindon:So, we had this thesis in mind. And ironically, probably six months later, Amazon go kind of launch with the same idea. But we took a very diff-Stephanie:That's not an app. What year was this? And where was Amazon at then? Who solved it first?Lindon:Yeah. So, we thought of... Amazon probably thought of it first because they built it. But we thought about it as well. But we kind of took our idea. But we approached these stores and we just asked questions. So, I remember, it was during the winter of 2016. It was very, very cold. Every day I would wake up. Me and Ahmed would wake up at 7:00. We'd go down to the train station, and we'd just take it to any stop. And then, after we'd get off, we would just walk into any grocery stores that we see on Google Map. And it's a very different place.Lindon:You go in, and a grocery store would be like, "Well, what the hell are you guys doing? If you're not buying anything, just get out." So, we went through a lot of that. But there were grocery store owners and managers who were willing to talk. So, we just asked them, "Hey. What are some of your top pain points? And what are some things that we can do to help you innovate your store?" And interestingly, we saw a huge amount of sentiment from the grocers and retailers who are telling us that they do want to innovate. But their concern is that a lot of innovations requires a lot of infrastructure, operational maintenance, and overhaul. And that makes it very, very difficult.Lindon:So interestingly, when we presented our "Amazon go" idea to these store owners, most of them freaked out. They were saying, "Hey. Why are you trying to renovate my store? How much does this infrastructure cost?" I'll say, "A couple hundred K." And they would say, "Look dude, even if you give it to me for free, I wouldn't want it." So, I was shocked.Stephanie:[crosstalk]Lindon:Why? Yeah. And they were like, "Look. It took me six months to install wifi and amplifiers in my store, because I need to rewire my ceiling and install amplifiers in the gigantic store to make sure everything is in line. Do you think you could come into my store to renovate my entire store, and install thousands of cameras? And do you actually think that could work?" So, we're saying... So, we're like, "Okay. You're right." And the store owner's said, "If you want to make anything work in this industry, you have to make sure that it is something that you bring it to our store and it just works. It shouldn't require infrastructure overhaul. It shouldn't require operational overhaul."Lindon:So, we really put that to note. So, we kind of went back to the drawing board, and we thought about, "How can we build a technology that just works?" And we kind of stumbled upon this idea that, if we compact computer vision and sensory fusion directly into a shopping cart, which is the most common tool in physical retail, we could enable the same type of experience at much lower maintenance. That really also tied back to our first idea of why we failed the smart security tag idea, was it would require a lot of operational maintenance.Lindon:And we thought that the smart cart could really overcome a lot of these barriers. So, we built the technology. Actually, before we built it, we just did a 3D rendering of the cart. We took it to the store owners. And immediately, within two months, we signed over probably 30 contracts. So, that was when we saw a huge pick [crosstalk].Stephanie:With the cart that didn't really work? The cart was...Lindon:A picture. It was not even a cart that didn't work. It was picture rendering of what it looks like, and I just described what it would do. And the store owners were very, very interested to sign on. So, that was how we got started.Stephanie:Okay. Cool. So, you got 30 new contracts. I'm guessing you had to go out and raise some more money though. Because, with only a couple $100,000 in the bank, even with 30 contracts, I'm assuming you wouldn't have been paid... at least net 90, probably, or more. What did you guys have to do to get that first version of the cart made?Lindon:Yeah. So, very interestingly, and very luckily, my co-founder, hardware co-founders father, actually owns a manufacturing facility in China. So, we have a very-Stephanie:Lucky, lucky.Lindon:Yes. So, we had a very unique hardware advantage in that we were able to prototype, and built our first versions of the shopping carts directly at his factory. And that was also one thing that, I would say, is our unique competitive advantage, in that we're able to iterate all hardwares on a monthly basis. Typically, it takes six months to iterate, on a typical hardware. It takes us a month. And that was the reason why we're able to accelerate our product development cycle so quickly.Stephanie:What were some of the early features in the cart that you either got rid of... What does it look like now versus when you first created it.Lindon:When we first created it, it was a lot of duct tape, a lot of weird components in there. I think I remember, when we built our first version, we were trying to demo this to a very large European client. And we shipped it over to France. And the entire cart broke. And I spent two days in a hotel just piecing things together before my client meetings. I actually used glue in there too.Stephanie:Oh my gosh. And it wasn't computer driven at that point, right? Or did you already have AI in it, or not yet?Lindon:Not yet, at the time, because our idea was that AI was going to take a little more time. So, while we're building the R and D branch of our government, we were going to go to market first with the barcode scanning version. And that was a very explicit strategy that we had, because we didn't want to be a heavily research dependent or research oriented company. We wanted to go to market, to understand the market as we go.Lindon:So, we built the shopping cart with a scanner, with a screen. And it also has a low cell which measures the weight of what's inside the basket. And I remember, when we first launched a very, very small trial inside one of the stores in Long Island city called Ruth Seller. We saw users try to use it. The scanner was very... It was a very small scanner that pointed at the side. And no one knew how to register the item into the cart. So, we did a lot of different changes to our scanner model, changes to the screen, and the low cell. And also, low cell was very, very difficult. Because it's not common knowledge that the scale is inside your grocer...Lindon:Your typical grocery stores are regulated by the government. It's regulated by the consumer affairs, because if your apples are a dollar per pound, and your scale is off, and it's wrong, then you're cheating the consumer. So, it's protected by the consumer affairs. And to be able to pass that certification requires us to send them our cart. And they will put it in a furnace, put it in a freezer, put in automatic weight into our cart and out of our cart 400,000 times. And we need to be reading accurate to 0.005 pounds. So, there's a lot of additional engineering in a hardware infrastructure that kind of went in there just to get the first versions of the carts right.Stephanie:Wow. That's intense. So, early days, it sounds like the cart was... It wad kind of like having a checkout conveyor belt on the cart. You could scan it. You could weigh things. And you could check out. And that was the gist of it.Lindon:Pretty much.Stephanie:What does that look like today?Lindon:So today, it's completely computer vision powered. We could directly drop items into the cart. And we're launching these into retailer stores very, very soon. And it's one of the paths where we took, where we thought about, "How do we make computer vision scalable?" Because inside a typical grocery store, you have at least 50 to 100,000 unique items. And for each one of these items, we need images of what the item looks like from different angles.Lindon:So, in a way, when we started building the scan version of the cart, it really paved the way for the scan less version. Because, as customers are using it, they're collecting images for us. You scan a Coca Cola. You put it inside the cart. Now, we know this is a Coca Cola. And then, using our cameras, we're able to collect over 120 images for us to train. So now, we have over 100s of millions of images in our data bank. And now, we're able to directly enable the scan less version of the cart.Stephanie:That's smart. That's like Tesla, how it's always kind of learning as it goes, learning from other cars. You're learning from every time someone's putting something in the shop.Lindon:Exactly. Exactly.Stephanie:That's great. And then, I also read that it does some product recommendations. Tell me a bit about that.Lindon:Yeah. So, you actually tapped into a really, really interesting space. Product recommendation is a big part of our system. Because when we walk into a store, and you shop for groceries, typically you will probably spend 30/40 minutes in there. And you probably spend five minutes at the checkout, but 35 minutes in your journey as you browse through the store. And when we were launching the carts and working with grocers, we realized that the bigger piece of the opportunity in innovating retail is actually not automating checkout.Lindon:That's a piece of the experience that we can make very seamless. But it's not the whole picture. The whole picture is, how can we help customer shop through the store during that 35 minutes, and provide them a very digitized and personalized experience. So, the personalized recommendations is a part of that which drives the digitization of the store, where if a customer puts in the milk, for example, we could give them recommendations for cookies, Oreos, cereals, and so forth.Lindon:And, as we go on, we're going to start implementing, for example, things like recipe recommendations. "Hey. I notice you have pasta and you have meatballs in your basket. Would you like to have some Parmesan cheese to go with it because we notice that you might building a recipe for meatball pasta?" Or "We notice that you have gluten free items inside your basket. Would you want us to recommend additional gluten free items inside your basket?" And that really creates another layer of digital platform, on top of physical retail, that really never existed before. Right? You have ecommerce, which is a gigantic digital platform. But also, now, in the physical stores, you have a digital platform where you could browse through the stores and interact with items around you through Caper.Lindon:We could eventually help you trace the roots of where your products are coming from. We could also help you count calories of what you've been purchasing. So, there's a lot of different ways to play in this market right now. And that's the most exciting part.Stephanie:Yeah. It also seems like there's an opportunity to kind of see the location of the shopper, and showcase coupons or things like that, based off the aisle that they're at. Because that's always something I think about is... Getting a random coupon in the mail, you're like, "Well, I'm not going to that store. And now, I forgot about it,' versus if I'm there, and I'm on that aisle, and it's like, "Oh. You can have a dollar off an egg." Okay. I'll get those eggs then, much easier by-Lindon:Exactly.Stephanie:... transaction than trying to bring something in store.Lindon:Exactly. Exactly. And through that... So now, we have some basic recommendations plus nearby deals. And we've been able to see average basket size pick up in some of the... I can't talk about the larger stores, because we're [inaudible]. But the smaller stores, we've seen more than 18% average basket size increase, on a very consistent basis.Lindon:Because if we're able to get the customers to buy a couple more things, that actually drastically helps the retailers top line as well.Stephanie:Yeah. So, tell me a little bit about, what does the landscape in general look like for autonomous check? I mean, now we're talking about location based stuff, personalized stuff. How do you view it interacting with ecommerce? What does the omni channel experience look like over the next couple years? Or what are you guys planning for?Lindon:Sure. So, I could start by just talking about the autonomous check out market. And maybe we can probably dig a little more into the ecommerce part. So, here is the general landscape. Basically, you have the Amazon go formats, which are... The start ups, little companies, are building cameras on the ceilings to directly enable all cashier less checkouts. So, this means that you will have to install hundreds of cameras on your ceiling, on top of building a process, and installing GPUs inside the store to make sure that we're able to process all these images and make sense of it.Lindon:The cameras will be used for two purpose. The first purpose is object tracking, which is you track how people are moving around the store. Because you need to apply that item to that particular person so we can't lose track. The second part is the cameras are also being used for pinpointing where items are inside a store. So typically, what a lot of... We've seen companies where, basically, they use cameras to label where items are inside the store. So, they don't directly do recognition of that particular item, but they label based on where it is inside the store.Lindon:And then, there is the other form factor, which is, instead of using the cameras to label where items are in the store, they use smart sensors, basically weight sensors inside the store, where if you pick something up, the weight sensor would detect it and it will know, "Okay. Coca Cola weighs 100 grams." So, you just picked it up. You picked that one bottle of Coca Cola. And that's what Amazon does. Amazon does a lot in Amazon Go. And then, there's the other form factor, which is a lot more similar to, basically, what Caper does right now, which is we compact everything into a device like a shopping cart, or shopping basket. And customers will pick it up and directly use it.Lindon:All the compute is done locally inside within this boundary. And it's also very, very interesting. I think, probably three months ago, Amazon Dash Cart came out, which is the smart cart iteration of the Amazon Go store, which I thought... And I thought it was very, very encouraging for the industry, because Amazon is known for their innovation in the physical retail through Amazon Go. And Amazon Go has been scaling to have 20 stores or so. And all of a sudden, they came out with Amazon Dash Cart. Because everyone thought Amazon Go was going into Whole Foods, was going to go into Amazon Fresh, but it didn't. And that was precisely the moment when we were happy to find out our thesis has been right all along.Lindon:Because we went out there to talk to the grocery store owners. And they told us that it would be operationally intensive to maintain. So, that's kind of the landscape. And then, beyond the Amazon Gos and the Capers, you have additional self scanning apps, which Walmart had implemented before in their scan and go program. That really didn't really take off, so they canceled it and kept it to a smaller membership, like Sam's Club, I think. But that's kind of the overall field. When you're really thinking about which type of form factor works, again, kind of going back to my earlier point, the most important factor is return on investment for retailers.Lindon:If they're investing in the technology, what is the cost of the technology? And what is the cost of maintenance for the technology? For in our security tag example, the cost of the technology is low. Each tag costs like eight cents. It's not worth too much. But the cost of maintaining the technology is big because I need to get the store staff to consistently apply it. One of the concerns on the maintenance of the technology for the Amazon Go form factor, is that it requires the stores to consistently update where all the items are inside a store. So, you definitely need someone else in the background to monitor and make sure your inventory is 100% accurate. Otherwise, you're going to start catching the wrong items.Lindon:With Caper, on the other hand, with our thesis, is that you could do whatever you want inside a store. It's none of our problem. All we care about is what you put inside the basket.Stephanie:Yep. One thing I'm thinking out too is, how do you continue the conversation with people who use Caper shopping carts? I mean, to me, I think of it as, if you at least have an app, you kind of can continue the conversation with that customer once they leave. When they come back in the store, it's like, "Oh hi, welcome back. Here's what you got last time." I'm even thinking about Whole Foods and Amazon check out on Amazon right now.Stephanie:How do you guys think about keeping track of consumers in a way that's helpful and personalized when they get back in the store?Lindon:Yeah. So, that's an awesome, awesome question. And this is something that we've been thinking about a lot, which is, how do we tap into consumers? Right now, one of our first ways to do this is to interact with them through the receipt that we sent them. So, we personalize the receipts. We can send them recommendations on the receipt. And when you come back, we give them unique identifiers that they could log in and we could recognize them. On top of that, we also integrate with retailers loyalty program, so that we're able to track and we're able to understand the shopper's purchase history.Lindon:So, that's kind of one part of it. The second part, which is more of a long term vision is, as we increase penetration in the market, we want to come out with a Caper app, where you could track... Shopping lists is one of the biggest pain points that we have heard from our shoppers. They want to be able to build shopping lists, and come into a store, and upload it inside in our cart. And then, we'll tell them where everything is inside the store. So, that's one piece that we're going to build in. And two is, we really want to build something that's a little more what we will call the Caper lifestyle.Lindon:What the Caper lifestyle is, is that, your diets and what you eat are guided by AI. So, if you have a particular fitness goal, when you go into a grocery store, we give you recommendations of recipes of items that are going to help you get there. And that's a much, much more healthier, and more informed, and AI driven lifestyle that you could pick up. And... Yeah. That's our very exciting future vision, but we're not quite there yet.Stephanie:I mean, that's really cool. That's just... I mean, it's like the trends right now you see around media blending with content and tech. And that kind of seems like where you guys are headed is starting here, when it comes to the tech piece, and then start introducing the media and functionality, community building, and encouraging healthy behaviors based off what someone wants to do. That's awesome.Lindon:Completely. Completely, because we interface with the customers, at the right place, at the right time, right, as they're inside, in their store, as their deciding what to buy. So, we have a lot of opportunities to provide our recommendations to the customers. And hopefully, that can enrich their shopping experience.Stephanie:Yep. I also like that you guys have the ability to track based on the receipts. And it just kind of opens up a whole discussion around making things that maybe were normally not useful, like a receipt where it's like, "Well, I'm not going to return any of these groceries. Just throw it away." Putting something on there that makes you want to keep something. And it's kind of like finding-Lindon:Completely.Stephanie:... arbitrage opportunity that maybe many are overlooking.Lindon:Yeah. One of our mottoes is, "Making the mundane into something magical". So, that includes making the shopping cart into something that's magical, so that when you put items in there, we just magically recognize it, into something like what we just talked about on the receipt side. It's not... traditionally, not very interesting. But we want to start enriching every part of your shopping experience that way.Stephanie:Yeah. That's cool. So, you're talking about increasing market penetration. And I saw that you guys signed a big deal with Kroger. So, I want to hear... First off, congrats. That's amazing. I want to hear a little bit-Lindon:Thank you.Stephanie:... about that. How did you strike up that partnership? And what does that look out on a national roll out?Lindon:Yeah. So, it's a very, very exciting deal because it is definitely a step towards the right direction in terms of accelerating the adoption of digitized stores. And Kroger's came to us initially. We had reached out them. But I would say a good portion of our clients are most effective when they reach out to us. And that was a part of... the early part of the process as to how we got to know Kroger, or how we got started on the project.Lindon:They've been looking into this phase and thinking about what could potentially make sense. And we decided to start working together, very fortunately. And throughout the process, there were definitely a lot of learnings. But fortunately, Kroger wasn't our first client, so we had gotten a lot of the initial warp up out of the way. And so, we were able to deploy in their stores very, very quickly. And I think one piece that was quite interesting was that, when Dash Cart came out from Amazon, it really accelerated the Kroger's process. Because there they were, Amazon, making additional innovations inside physical stores, and now they're actually... Before, people were saying Amazon Go wasn't going to scale to a larger store.Lindon:And Amazon proved people wrong by developing the smart cart. And that was a validation of what we have built. And that accelerated the process as well.Stephanie:What kind of lessons did you learn, or would you tell someone else, when you had that first partner versus moving to something like a Kroger?Lindon:It's definitely night and day. We started first by working with a local grocer, a smaller grocer called Food Cellar. The store owner's extremely friendly, very open minded, wanted to try new technologies. So, we launched with him first. But as we started working with him, we realized that grocery is a extremely complicated market. It's not like a typical convenience store where everything is just bar coded and stuff. Inside grocery stores, you have promotional deals. Buy one, get one free. Buy one, get one 50% off.Lindon:The promotional part of the pricing logic was very difficult. And also integration into the store's system was also very difficult, because we need to connect to their point of sale system to make sure that we know the latest pricing of what costs what. And we also need to push back that information to their inventory systems to make sure that their overall records are well maintained. So, that part also took a little bit of time. But I think most importantly is really just figuring out the overall flowing process. In grocery stores, you have... They sell produce. Produce are weighted. So, how do we facilitate that to make sure that it's very easy for customers to understand that this is the way that they add produce?Lindon:On top of that, there is also buffets, coffee beans, beans, different types of... They also have a bakery with coffee. And they also have a pizza little section in the store. So, really understanding every single part of that was very, very essential. So, we really learned... We did a lot of learnings at the local grocery store level. And we also ramped up to Kroger. And before we launched Kroger, we actually launched Sobeys, which was one of the largest super market chains in Canada. And by that, we've realized the complexity of a larger enterprise organization, how their system is structured, how their processes work.Lindon:And then, all through all that learnings, then we started working with Kroger. And with Kroger, we're still learning along the way. Physical retail grocery is a complicated space, but we have really figured out a lot more things. And now, we're able to move a lot more faster.Stephanie:Yeah. That's very cool. It also seems like there's going to be a tipping point where you train the machines, and then just so much data. But then, you don't really have to do that anymore because there's only so many products. There's only so many bottles of ketchup.Lindon:Right.Stephanie:Where it's like, "Okay. I know what that is now." As you start rolling out into future stores, it seems like you'll get over a hurtle, then it's kind of like on to the next thing because you've tackled that and they're good.Lindon:Yeah. Completely. Because the initial wrap up is always the toughest. But once you kind of get through a certain critical point, then you realize that, "Okay. We have all the images that we need. We have the integration system, the infrastructure we need. We have overcome a lot of the hardware issues," which I didn't mention. The hardware issues are also another beast. And so, I think, from our first store, which it was probably launched about a little over... probably over two years, until now, we just learned a ton along the way.Lindon:So, we really... A demo environment... Coming out of a demo environment/a pilot environment into actually a production environment where customers are using it on a consistent basis, where thousands of transactions go through our system on a daily basis, it's different scale. It's a different beast that we have to manage.Stephanie:Stephanie:And did Y Combinator come back to you now that things are going pretty well? Or did they ask to invest now?Lindon:Well, Y Combinator has always been a co-investor along the way.Stephanie:Oh happy, I thought they didn't... Oh, Y Combinator. I'm thinking about the investors at Demo Day.Lindon:Oh. The investors at Demo Day, yes. But we're a little too big for their tech size now. So...Stephanie:Yeah.Lindon:Definitely, when we started building and started fund raising, it was a different product. And it was a different market dynamic too. Back then, it was like 2016/2017, there were... Cashier less check out wasn't even a concept. It was like back in 2008 when self driving wasn't even a thing, and you were trying to build self driving. People were like, "You're crazy." Cashier less check out for retail is kind of very similar to that.Lindon:But I think a lot of the recent tailwinds in the industry... It really started first with Amazon Go. And then, Amazon acquired Whole Foods. So, it really spurred up Amazon's intention to tap into the physical retail market. So, it got a lot of people nervous. And then, it kind of evolved into... Recently, you have COVID, which accelerated the need for a more automated checkout process, because cashiers are very prone to COVID risk. You see more than 20% of cashiers were diagnosed with... tested positive with COVID at some point in their lives. And that makes it a very difficult decision for both the retailers, and the shoppers, and the cashiers. Because you have cashiers who are consistently exposed to thousands of people on a daily basis.Lindon:Shoppers want to make sure that they're safe. And retailers want to make sure that their shoppers are safe, and their employees are safe as well. And that kind of accelerated the interest in the market.Stephanie:Yeah. Do you see curbside pickup and people shopping for you as a threat to the business model?Lindon:Yeah. This is very interesting. So, this kind of comes back to... draws a full circle on the ecommerce portion now. I do think that grocery and general retail is going to continue to be more ecommerce. That's one part that I definitely recognize, and definitely am aware. And ecommerce is very interesting in that, during COVID, physical stores are actually doing substantially better. Because we systematically shifted the demand from food, basically from restaurants, into cooking at home for yourself.Lindon:So grocery, general retail, kind of enjoy a lot of that market expansion. And then, on top of that, then ecommerce came in and chipped a little bit of the market away from them. But then, when you actually think about the overall landscape of retail, Instacart is the largest ecommerce player. 100% of their transactions are [inaudible] physical stores. So, it doesn't reduce the traffic inside stores. If anything, it really increased the need to be efficient inside a store. And that's where Capers come in as well. We can help facilitate delivery shoppers to make them more efficient by telling them where all the items are inside the store, and get cashier check out free so that they can walk out of the store.Lindon:So, curbside pickup also, also the same. You need someone inside a store to go walk around the shelves to pick up everything. So, where I see the future of retail really converging is that you are going to see a lot more retailers. Not only are they going to optimize their stores for the shoppers, but they're also going to optimize the stores to make sure that it also becomes the local fulfillment center. Because these are the distribution modes that are closest to your house. These stores are just a mile away from your house. So, I don't see in store activity going down at all. In fact, I see in store activities... It's going to continue to pick up.Lindon:And that also increases the need for technologies like us to make in store experience more pleasant so that, when people come back to the store, they enjoy and love that experience as they interact with food around them, but also make it extremely efficient and expedite it. So, I'm very bullish on the overall check out free industry.Stephanie:Yeah. I see there being opportunity as well, expanding into the Home Depots of the world, and all the stores where it's like, "Ugh. This aisle is a little too much for me. I just need to know where to go to get what I want, and then just walk out and not wait in a crazy line." So, it seems like there's a lot of other industries that would probably be waiting for this...Lindon:Completely.Stephanie:... after you guys were fully secured.Lindon:Completely. We could expand to all retail formats. So, we're very excited to explore that.Stephanie:Cool. All right. Well, this has been such a fun interview. I probably could keep going, but I'm going to shift over to the lightning round. The lightning round is brought to you by Sales Force Commerce Cloud. This is where I'm going to ask a question, and you have a minute or less to answer. Are you ready?Lindon:Okay. Sure.Stephanie:All right. What's one thing from 2020 that you hope sticks around in 2021?Lindon:That's a really tough one.Stephanie:It can't be like, "Oh. I hope people continue to shop more in person and not go to restaurants." It can't be something that benefits your business.Lindon:Okay. I hope that my team momentum keeps up, because 2020, ironically, is one of the years where my team has really gone together, despite COVID, and really accelerated our development. So, that's one thing that... That was good. And it really proved that work from home... Actually yeah, work from home is here to stay.Stephanie:Yeah. I agree. People will not want to go back five days a week anymore.Lindon:Yeah.Stephanie:What one thing will have the biggest impact on ecommerce in the next year?Lindon:Cost of delivery. If cost of delivery goes down, ecommerce would also take off.Stephanie:Yep. If you had a podcast, what would it be about, and who would your first guest be?Lindon:The cockroach way. I thought about that. I was going to write a book about it.Stephanie:About what?Lindon:How do you survive building a startup, earning, I don't know, $2000 a month. It was one of those things. Because we burned $7000 per month for two and a half years. So, not buying orange juice and all that stuff, that was real, and definitely want to talk about that. So, who would I want to invite? An entrepreneur that was very referable, very, very cheap.Stephanie:Your co-founder?Lindon:Yes. Yes. He will be a great one. He's still referable today, even though our team [crosstalk]. Yeah, at least... Well, I mean, I'm paying for it myself now. It's not on the company. So, he can't stop me.Stephanie:There you go. What's up next on your Netflix queue?Lindon:I watch a lot of stand ups, Kevin Hart.Stephanie:Yep.Lindon:Yeah, it's awesome. After a long work day, you can sit down and just watch some Kevin Hart.Stephanie:Yep.Lindon:It's great.Stephanie:Right. And I think you'll have a good answer for this last question. What one thing do you not understand that you wish you did?Lindon:The complications of scaling a team. When we scale from sea drown to the series A, to beyond, my role has really evolved from a independent contributor that's on the route to execution, to middle manager, which is managing the execution level people, to managing middle managers, to managing managers of middle managers. And along this way, I really learned a lot about management and growing as a CEO. So, that was something that I wish I had known a little earlier, so that I'm able to roll my team along more effectively.Stephanie:Good one. All right, Lindon. Well, thanks so much for joining the show. It was a pleasure to have you on. Where can people find out more about you and Caper?Lindon:You can find me on LinkedIn. And you can also find out about Caper on Caper's website, caper.ia.Stephanie:Awesome. Thanks so much.

From the baseball field, to the Nascar track, to the tennis court, in sports, ads can be found everywhere. Brands and sports have been linked together through sponsorship for decades. And now, with the rise of social media and influencers, athletes can create even more profitable relationships with brands than ever before. But a sponsorship should be more than just a way for a brand and an athlete to make money. Today, more than ever, that message matters. The story you tell makes a difference. And the purpose behind a brand is what is drawing people in and converting them to loyal customers. At POC, that belief is what has been driving the company since its founding, and it is influencing its unique content strategy, which is successfully driving people to its website and into its ecommerce channels. POC is a Swedish company that makes top of the line protective gear for athletes around the world. David DeMartini is POC’s Global Chief Marketing and Digital Officer and on this episode of Up Next in Commerce, he explains why the purpose- and data-driven content strategy the company has  devised is working, and what other brands can learn from what they have built. Whether it’s more of a focus on original, serialized video, or a different approach to working with influencers, POC’s marketing strategies have far outperformed traditional methods. Learn how and why on today’s episode! Main Takeaways:Propose a Purpose: More than ever, consumers are driven to brands that have a clearly-stated purpose or mission. But simply having a purpose written out on your website is not enough. Brands that develop an ambitious purpose, stress test it, and look beyond the problems of now to understand how their purpose can drive them in the future are the ones that will succeed.Don’t Be Old School: Athlete sponsorships are not new in the marketing world, however, brands like POC are finding creative ways to expand those partnerships. By investing in different marketing channels like video series, movies, and other long-form, engaging content, brands can set themselves apart and tell stories in ways customers will connect with. More Than The Data: Every organization should be using data to guide organizational decisions, but data should never be the only factor. Data should be used in conjunction with what you know about your customers on an intangible level to create a balance that is analytics-based but still feels human.For an in-depth look at this episode, check out the full transcript below. Quotes have been edited for clarity and length.---Up Next in Commerce is brought to you by Salesforce Commerce Cloud. Respond quickly to changing customer needs with flexible Ecommerce connected to marketing, sales, and service. Deliver intelligent commerce experiences your customers can trust, across every channel. Together, we’re ready for what’s next in commerce. Learn more at salesforce.com/commerce---Transcript:Stephanie:Hello, and welcome back to up next in ecommerce. This is your host, Stephanie Postles, co-founder of mission.org. Our guest today is David DeMartini, the Chief Marketing Officer at POC. David, welcome to the show.David:Hi, Stephanie. Thank you for having me. I'm excited to be here.Stephanie:Yeah, I'm really excited to have you too. I just went into a Wormhole watching some of your guys' videos with the skiers, flying down the mountain at lightning speed and I was like, "Could I do this? No, probably not." But they were great to watch.David:Yes. Oh, well, thank you. And I sure you could do it. We have an amazing roster of athletes that do a great job of telling our brand story through their actions and our goal is to do everything we can to keep them safe. So, it's fun to create content or let them create content and it helps us tell our story.Stephanie:Yeah. I love that. We'll definitely be diving into all of that in a little bit, but first tell me or anyone who's listening, what is POC?David:Yeah. So POC is a Swedish company that was founded in 2006, 2007 timeframe. We are a protection brand. We're the world's leading protection brand, currently servicing athletes and participants across bicycle sports and snow sports. And so, we have a really strong mission and purpose to save lives and protect those pursuing their passion, and enable people to really find more joy in life through using our products to keep them as safe as possible when they're doing the things that they love.Stephanie:Yeah. And you have very nice looking products as well. I haven't been snowboarding in a while, but I'm like, "If I was, I would want this helmet here and they even have mouth guards nowadays, which is mind blowing to me." I mean, very helpful, but I have not seen any other companies. You have a helmet with a... Is it called a mouth guard? What is the word for that now?David:Yeah. Well, on the snow side, we have a couple of different disciplines that we service. And I think the product you're referencing is one of the helmets we have on the race side of our business. When slalom skiers or even some GS skiers are running gates. There's a chin bar that attaches to the helmets to make sure none of [crosstalk] end up smacking them in the face as they're making their way down the course. So, always looking for ways to better protect our athletes in our customers. And that's a pretty handy service with that chin bar because taking a slalom gate to the face is not much fun.Stephanie:Yeah. It does not sound like it. I also looked at them like this would be perfect for my two and a half year old, and he is always falling and hitting his face somehow, or his chin I'm like, "You guys need some kids versions of this."David:Yeah. That's a good point. We have an amazing children's line that we call poquito-Stephanie:Oh, cute.David:Kids helmets and there's some really cool safety pieces built into that. We found that the most accidents that happened with kids on a ski slope or on a bicycle are scenarios where someone larger than them, whether it's a larger kid or an adult just simply doesn't see them. And there's a collision that happens. So we have a really great visibility story built into our kids' products, but we hadn't thought about the chin or face protection for the children, but maybe we [crosstalk 00:03:28]. Yeah?Stephanie:Yeah. So when I was looking through your LinkedIn [inaudible 00:03:33], I also saw that you have a background in media and sports, and I was wondering what drew you over to POC?David:Yeah, so I of cut my teeth at an agency in Colorado working across an amazing book of brands that the agency Backbone Media service at the time. And it was really an amazing opportunity for me because I got to really dig in and understand some of the challenges that brands have really all maturity level, where we're trying to overcome. Everything from a larger, more established brand, like Eddie Bauer or YETI Coolers, all the way up to startups looking at how do they just continue to raise some money to propel their businessDavid:And so, as I was working through and learning and absorbing and working with all these amazing people at Backbone Media, I was really fine-tuning the things that were interesting to me and knew I always wanted to be in marketing and direct-to-consumer but really found an understanding of what specifically in those areas were interesting.David:And then after about five years with Backbone, POC was one of the clients of Backbone for a long time. And one of the accounts I worked on and an opportunity came up to join POC internal as the marketing director for North America and I took that and I've been lucky to find myself in some opportunistic positions within POC. And my skillset has allowed me to rise to the ranks here as well which has been really fun and really rewarding.Stephanie:Yeah. That's great. I also love how POC has the same messaging across all the platforms. It was very clear about what you guys stood for. So tell me a little bit about... Did that draw you in when you saw, "Here's our purpose. Here's why we're here." How did that impact your decision to jump over to work with them?David:Yeah. I think that one of the key attributes that you see as particularly important and something that a lot of brands in the outdoor space focus on is purpose. And the term purpose can be applied to business or the way that a company operates in a lot of different ways. But I realized early on that a trend that I was seeing with the brands that I worked with at Backbone Media, the ones with a solid foundation, a clear purpose and a really clear and ambitious but not to the point where the brand platform and the mission of the vision didn't really mean anything. Those are the companies and the brands that were doing the best.David:And so, I quickly realized how important that was. And so, as I thought about what was next, I knew that, that was core to any organization that I could see myself at, for an extended period of time. And so I made that one of my priorities and starting to look around for whatever was next for me was that purpose has to be there. And I have to really be able to connect to that purpose in a meaningful way because if I can't, in a lot of ways you're trying to fake it to make it, and that just gets really taxing and is tiresome and hard to do. And it comes back to, if you can act to the purpose it's very easy to find the motivation to really give everything you have to the business and these days you have to do that.David:So, POC has had it. It's a really amazing a brand platform and admission and vision. That's been with us since day one and credit to the founder, Stefan Ytterborn who created the brand in 2006, to address a problem that he saw in the form of... His kids were becoming ski racers. And he looked around at the head protection at the time and said, "This doesn't seem all that great and I think I can do this better." And had the foresight to realize that spending the time and really ironing out what he was there to do and what their mission and vision looked like, was crucial to make sure he built something that could continue to live on and be successful.Stephanie:That's great. Your kids always seem to be a driving force sometimes with businesses or new products. And I love that story, having an actual reason to develop something and being like, "Oh, everyone actually needs us in this industry. And it's not good enough. I'm going to fix it right now."David:Yeah. He saw a problem that was specific to him and where he was in his life and realized that, he's probably not the only one feeling this way and really created something special and it's been a fun ride since then and continues to do well. So, again, it goes back to the core purpose of the business is real and meaningful. And that's really valuable and making sure that we make the right decisions on a day-to-day basis.Stephanie:So, since you've been able to see many brands, especially why you were working at the agency, what are tips or best practices around maybe a new brand coming up with their purpose, but then actually following through, because I think that's a tricky thing with a lot of these new companies popping up it seems like a lot of them say they have a purpose or here's what we're doing, but it doesn't actually come through. It's just like the messaging. You don't see actions behind it. Is there any advice or things that you saw when you were at the agency of like this work and this did not work, everyone should not do it this way?David:Yeah. It's a good question. And I think the answer to that can take many different forms but really what you're looking for is something that's balanced in something that is, it can stand the test of time. And so what I saw at Backbone was it used to be that you could identify a problem, find a solution for it, and then take that and run with it. And I think that that worked for a long time and that was the traditional approach to starting a business. But I think the consumer today has evolved so much to where they look for more than just helping them solve a problem. You really have to be invested in the solution and in the problem itself to a point where it's authentic and real.David:And so I think for anybody who's thinking about starting a business and can't stress enough, the importance of making sure you spend the time and put the work in on building a brand platform and then pressure testing that through all different mock scenarios thinking about where you're going to be in five years, 10 years, 15 years, and beyond. And making sure the verbiage you use in the core of that brand platform can remain constant. I see if a new company is... It's almost like you can't be too focused on the problem you're trying to solve, you have to think beyond that problem, that future problems, and make sure that your approach and what you're creating can solve future problems as much as it can solve the problem here and now.David:And it's a really hard thing to do, and it takes a very specific approach and creative mind. And it's not easy to achieve. And so I feel lucky to be part of an organization where, we were able to achieve that. And the founders that started POC went through that exercise and it's cumbersome and difficult. But I think it's super important.Stephanie:Yeah. I completely agree. It reminds me of... I don't know if you've heard of the, Clock of the Long Now, it's a 10,000-year clock, and it's all about encouraging long-term thinking. And every time I start thinking about longer-term thinking, and where is this headed? I always think about that clock, it's my motivation.David:Yeah. I think that's a great connection point. And it's really hard to visualize and come up with mock scenarios as to what could happen in 10 years because who knows what's going to happen in 10 years. But I think just going through the exercises and putting the time and the effort and we'll help you find the right balance between to immediate here and now, and then on the other end of the spectrum is... I don't know if you know a guy named Scott Galloway, but he uses the term, yogababble where you use so many buzz words and it's so conceptual that it actually completely loses all of its meaning. You got to find someplace in between there that is balanced and can stand the test of time to a certain degree.Stephanie:Yeah. That's a good mentality. I saw you have another title, which you didn't mention in the intro, and I'm not sure why, of executive producer. I was looking at the one video, American Downhiller, which is really good. I only got to watch 10 minutes of it, but I think it's a good segue Into some of your marketing and content strategies because the video was so well done. I mean, is it on Netflix? If not, it should be. Tell me a little bit about how you guys go about thinking about developing videos.David:Yeah. I'm really glad you brought that up because that's a really, really fun and amazing project that we just launched to the world earlier in... I think it was in October actually. I was going to say November but, launched in October with a world premier here in Park City, Utah, and then a distribution program with U.S. Ski Team and skiracing.com. And like I mentioned, we got our start in ski racing and it's incredibly important in Colorado business. Compared to other snow sports categories, or the bike category. It's relatively small, but it's so important because in the athletes... Really on any level that are competing or skiing gates on a consistent basis.David:I mean, that's where the stakes are at the highest. That the speeds are incredibly high. The snow conditions are ice essentially these days. You have skis with incredibly sharp edges and the possibility of things going wrong is quite high. And so, we work really hard to continue to innovate on behalf of the ski race community and find different ways to apply the different technologies and safety features that we develop to their world. And so, through the years we've become really close to this ski race community. Like I said, it's not a huge community, but it's very tight-knit one. And one that we're very happy and proud to be part of.David:And over the years, looking for opportunities and being very close with the U.S. Ski Team, we saw this story that was really amazing and hadn't really been told on a mass level around the men's speed team, and how brotherhood really formed through, I guess you could say it through unique adversity in the sense that no ski racing in the U.S. is not what it is in Europe. When you go to Austria, you go to Norway, you go to Switzerland, ski racing is... I mean, the Hanukkah in Austria is it's like the Super Bowl, it's a huge deal there. They have amazing massive fan bases and so being an American and on the American team, when you're competing, most of the races are in Europe. And so the challenge is that the U.S. team had to overcome were unique.David:And I'm not really qualified nor want to say that their challenges were harder or worse to overcome than some of the Europeans, but they were just different. You're not able to travel home on the weekends. You're spending so much time with your other teammates and it really cultivated this brotherhood that organically evolved into this story that became... They took the name American Downhillers, and that term became a tool to represent this brotherhood and the function of some of the veteran guys on the team working to help develop and help some of the younger guys that were coming up to the speed program navigate some of these difficult scenarios that they were in, where you're in foreign country, you're not able to see your family. You're not able to go home on a consistent basis.David:And really that story was just so amazing that we were working with skiracing.com, and we finally said, "Hey, let's try and tell the story." And so, it came to life and I believe it was 2017 where we started to do some short episodes in conjunction with skiracing.com. And we did that for two or three years, five minute, eight minute, 12 minute episodes, focusing in on different elements of this American Downhiller story.David:And towards the middle of 2019, we said to ourselves, "Well, these episodes are great but we haven't really done anything like telling the story from start to finish. Is something we haven't done and it would be an amazing piece for the ski race community." And so, we partnered with skiracing.com and a woman named Claire Brown, who's an amazing producer and has an amazing team of filmmakers. And she's been a part of the ski race community since she was a little kid and she raised competitively through college and I believe she was an All American. And as a staple in that industry and community. And so, we worked with her to tell the story. And so we were able to tell the story from start to finish and pull pieces from the different episodes that we had. And it turned into this really amazing piece that, gives some insight and some behind the scenes look into what it truly means to be an American Downhiller and then some of the challenges that they had to overcome.David:So a really, really fun project that Claire and Elizabeth Reeder, who's one of our Sports Marketing Managers, did an amazing job facilitating and putting together, and we're super proud of it. And we're excited we're going to continue on with this theme and this first one was focused on the men's team, and there's equally as interesting and amazing stories on the women's side. And we're excited to continue to tell these amazing stories that happen in American ski racing, and the next one up we'll be focused on the women's team.Stephanie:That's great. So, where does this content live? I definitely want to finish it. I mean, like I said, it seems like it should be on Netflix or something. It's very, very well done, very professional. It gets you right from the beginning with all the skiers hopping in and saying what it means to them. Where do you guys put this content after it's all made?David:So the distribution for it... We launched a lot of amazing new ski race product this season. And so, we had an objective to reach and engage and build our connection with the ski race community. So the initial rollout plan with this was to work with the U.S. Ski Team work with skiracing.com. and obviously we would support it as well, but we have it living on YouTube and we've seen really great results from an organic grassroots distribution plan. We are looking at some film festivals throughout the country over the next few months and have submitted it in a few of those and we are looking at some larger distribution. There's possibility that some of it might run on NBC, this winter, which would be amazing.David:And we're looking at the subscription viewers or platforms like Netflix and Apple TV and Amazon as well. And trying to figure out how we can get it up there. The goal with the larger distribution platforms is... Again, the story is what's most important and the story can help inspire the next generation of ski racers or particularly American Downhillers. There's a utility function to that and we want to make sure that, that's available to any and everybody that wants to see it on an ongoing basis. So there's a long tail distribution plan to this as well, to make sure that anybody who wants to learn and understand this story has the ability to do that through some of these larger platforms.Stephanie:That's cool. It seems like there's definitely a lot of angles. You've got the partnership thing going on. You've got... Yeah, being able to tell the story holistically, like you wanted to and then the long tail of possibly be able to sell products as well when people see them, yeah. At the perfect place, perfect time while they're watching it.David:Yeah. And we were very intentional about... We didn't want this to be something that felt like we were artificially trying to place product throughout it, the commitment was to the story. And like I said, we've been a partner with U.S. Ski Team for so long that now our product is visible, but you'll also see product from our competitors. And that's okay. We feel like if the story's great and we can help facilitate telling it we don't need a ton of branding. We don't need POC products sitting next to every interview or we don't need the traditional product placement in these stories, feel like we're doing a service to the community by facilitating telling it, and for us, that's what we're here for. So, we take a bit of a different approach to content than say some brands do or some brands previously have.Stephanie:Yeah. Well, how do you guys approach product placement? Because that seems like a very... I mean, it's always been around, but I see a lot of brands doing it way better now. I was just talking about it, the Netflix series of one about organizing and how well the container store did after that. And I don't remember really being slapped over the head with the branding, but it was more me wanting to check into it afterwards if like, "Well, what were they using to organize their entire closets?" And it was very organic. So I see brands doing a much better job now when it comes to product placement and partnerships around that. How do you guys explore that avenue?David:Yeah. So our sports marketing organization does an incredible job and partnering with athletes and getting our product on athletes has been core to our marketing strategy since day one. And so, again, do think it comes back to the purpose conversation we had and we are not delivering on our purpose if we are not supplying the best in the world with our products, because we truly do believe that they're the safest products out there. And so, as you mentioned it, when you take an approach of... We want personalities, we want athletes on our roster that have similar beliefs but of course their own brand and their own way of executing on those beliefs. But we want people who stand for innovation, progression, and we want to make sure that the partnerships we develop with athletes, we truly are helping them pursue their passion and helping them progress the sport that they've dedicated their lives to.David:And so, we have an amazing list of a roster of athletes that we're always looking at and adding to. We have some amazing development programs as part of our sports marketing strategy. We have a three layer level approach. We just launched a revised regional or grassroots athlete program that we call the Aspired Collective and that is solely intended to give up incoming athletes across both snow sports and the bike world. Give them opportunities and help them continue to progress in their careers to one day be the next superstar. And so, doing what we can to support the communities and support the activities in sports that we service through supporting talent within those categories you naturally find yourself with your product on the right people more often than not.David:And so, again, it's a little bit... We try and take a maybe a less manufactured approach and we don't go out and say next year we think so-and-so is going to be the best ski racer. So we've got to get our stuff on this person, this guy or girl, and then the next year it's someone else. And so we go after, we look for longer-term partnership opportunities people who truly believe in what they're doing and partnering with us helps them do what they're doing better. That's the stuff we look for.Stephanie:Yeah. It seems like athletes sponsorships, that's like the original [OG] influencers. Influencers are big now, but the sponsorships of athletes, it seems like it was already going on for a really long time. But what seems really hard to do is figure out how it's driving sales or how it's influencing your marketing campaign. How do you guys think about that when you're setting up these partnerships, you're picking out what athletes you want to work with? How do you think about what the end results should be outside of just wanting to work with a great person of course and making it long-term? What are some metrics you hope to achieve with these parties?David:Yeah. I think it's a really good question because I think the rise of influencer marketing has put such an emphasis on follower number and engagement metrics and all these things. And I think what we've seen is that those things are all important and I'll get into how we look at those, but you can't focus so much on just the numbers to where you lose sight of the individual, the personality, really the non-tangible that an influencer or an athlete or any partnership brings to the brand. And we've been very careful to... We have an objective to be results driven and measure what we can and take a data-driven approach of course but we also want to make sure we don't over index on that to the point where we lose some of the intangible stuff.David:So, when we look at an athlete, a lot of times their Instagram follower account or their YouTube page is an important metric and in the equation but they're also three or four other metrics that are equally as important. So we look at personality, we look at opportunity to have a longer-term relationship with this person. We look at how they compete, where they compete, these sorts of things and make a very balanced call on whether or not they should be somebody we should pursue or not pursue. But to answer your question about measuring influence that athletes or influencers have, it is difficult. And there are some data tools that we have, whether it's being smart about how you distribute content for them to work into their communication outreach with specific links and stuff that we can track through our website.David:But a lot of that stuff is specific to a single campaign or a single program and there's really not a great way going back to the equation that we look at, there's not a great way to measure the intangible stuff, but we know it's important and we know it's working and it's a core element of our positioning in the marketplace. And so, we measure what we can, but we also try and be real and be okay with... There's simply some things that are just hard and difficult to measure and we trust ourselves to say, "This is this things that aren't measurable, we can..." I trust our people and we trust ourselves to say, "This is worth the investment and it's providing a lift to our brand in a way that we just simply can't measure."Stephanie:Yes. What are some of your favorite marketing campaigns that you've done that you really remember, or that were most successful?David:Oh, that's a good question. Favorite marketing. The American Downhiller is definitely up there just because it was so different and new, and we'd never produced a feature like them but we've already talked about that one. Earlier this fall, we launched a signature series, excuse me, around Fabio Wibmer who's an incredibly talented mountain biker, whether it's trials or downhill riding or, dirt jump riding. He is arguably the most popular mountain biker in the world right now and we created a signature series with him that we launched earlier this fall. That's really, really cool and we took the approach of, "We're going to create the product for you, but we really want you to create the marketing and the messaging and launch this product in your voice."David:And that was a really fun approach to take to this because one, it took a little bit of the stress off us internally, and two, it allowed for our audience to hear a message that they're used to hearing from us, from somebody different, which I think in a lot of ways was quite refreshing and something different. And Fabio's team is incredible at creating highly engaging video content and his YouTube following is massive. And so, we basically said, "We'll help you make the product. We'll support some of the distribution of the content, but we want you to create that content." And so it was a different approach for us and a pretty fun one because it brought a different tone of voice to a launch than we're used to having.Stephanie:That's really fun. I mean, and a really good point because I can think of so many brands who work with people in their industry and they end up squishing their creativity by saying like, "This is our brand messaging. This is how it needs to be done." And you can tell you're like, "This is not Oprah Winfrey talking. This is not that Oprah does that." I don't know, but they squish the creativity of the artist or the influencer by all their rules. And it ends up not being very organic and then no one's following actually ended up connecting with it.David:Exactly. And the value that these athletes and influencers and anybody that we partner with bring to our brand is they have their own community and we want to help them build their own community. But if we come in and say, "You need to talk to the community that you've built in our voice and in the way that we speak and over-engineer that, one, their community is going to say, "This is stupid. I can tell this isn't new, or I can tell that this isn't the person that I committed to either through a click on follow or some other way." And if we give that freedom to the person to communicate the points that we're trying to get our audience to understand, and in the way that feels natural to them it's going to come off better, it's going to be a better end product in terms of the creative and again, it's going to resonate with the audience more effectively.David:And we lean on our athletes in our roster of partners very heavily because they're good at what they do. And for us to come in and say, "We know how to do what you do better," it doesn't feel right and I don't think it's right.Stephanie:Yes. So you had a good quote that I saw, but I'm probably going to botch it. So you can just tell me if it's wrong. It's all around data and you were saying that the data that you gather around your customers is your true North. And I wanted to hear a little bit about, what data do you look at and is that influencing your products, or how are you using it day-to-day?David:Yeah. I think that you got the quote exactly right so, thank you for that. And I guess maybe a little counterintuitive to my last point of the balance between tangibles and intangibles, but when we do have data available, we need to make sure we're using that. And we are still a growing organization and we are far from totally dialed in terms of our data management and pulling and curating as much data as we possibly can. But we have gotten a lot better at doing that, really the past three or four years. And part of being able to actually use your data effectively you have to start with your systems and your tech stack and we've been really lucky to be able to partner and use Salesforce suite of services with Commerce Cloud, Marketing Cloud, and Service Cloud.David:And the decision to run with those platforms was specifically so that we could start to organize our data and get our systems to speak better together and learn more about our customers. We have all kinds of different touch points with these customers. And the fact that Salesforce Commerce Cloud can speak with Marketing Cloud, and even with Service Cloud when we get a customer service inquiry that scenario really at least gives us an opportunity to maximize what we know about our customers. And so, like I said, we have a long way to go to be where I would say we're A+ rating in terms of data management,` but every day our team gets smarter and we make right the right decisions and we learn more.David:And I think in terms of using the data as your true north and bringing it full circle back to the idea of balance, you got to be able to analyze the data, understand what the data is telling you, but then put that information or that insight into the context of the other things you know about your customer base. I think one of the things I feel very lucky in that, we are a relatively small team, a marketing team of 25 or 28 people across both the marketing team and the digital team. One of the benefits of that is that, we don't have a lot of redundancy and every individual in the organization you naturally have to gain an understanding and you got to know our customer relatively well for almost everything that we do.David:And so, that contextual understanding and knowledge of our customer, coupled with some better data management and insight going actually does give us a pretty good understanding of our customer. What's important to them and how we can deliver on that. Whereas I think a lot of times in bigger organizations I've seen, if you have a lot of not necessarily redundancy, but a lot of very specified positions that do one thing and do one thing very, very well, it's a lot harder to understand the big picture and gain of an accurate profile of the contextual things that go along with your customers. And so, I guess what I'm saying is in a larger organization, it's very easy to look at the data and only the data and it's sometimes hard to bring your head up and look around and say, "Okay. Well, this is what this is telling me about this specific point or insight. How does that connect with what might be happening over here?" And so there's of course the challenges with being a smaller group but I there's also a lot of benefits and that's definitely one of them.Stephanie:Yeah. I completely agree. I mean, thinking about how do you get to that holistic approach where... I mean, I've been at larger companies before and things get siloed and you have your customer service team over here, and they're probably hearing so many good nuggets from customers about new product features they want, or something that might help the experience better or the unboxing experience. And a lot of times that they just get stuck there and you don't know how to incorporate into your new product launches and stuff. And so, I hear a lot of companies, especially smaller ones that are very quickly growing, experiencing issues like that, where things are all siloed and they don't know how to look at the data, but then also take a step back and use your gut and be like, "That's actually sending us in the wrong direction, or that's not really our customer who's saying that."David:Exactly. Yeah. Being a small group allows us to... Our customer service manager can easily stand up and walk across the room or these days, tap our Digital Director on the shoulder and say, "Hey, three of my team members said this and they're hearing this. What does that mean for what you do?" Those conversations are really, really important. And since we're lucky. It's a little easier for us to facilitate those just because we're a smaller team.Stephanie:Yes. So what digital trends are you excited about? Where are you guys headed over the next three years in the world of ecommerce?David:It's a good question but there's lots of them. I think one of the things that I'm seeing in and we're actually acting on is that, consumers are... Their expectations have evolved to a certain point to where the traditional tactics in terms of driving a sale, there's more options there. I think, you're seeing a lot of brands think about the needs of their customers and really looking at it and saying, we need to be able to add more value than we're looking to extract from our customer base. And to do that, you have to really think about what are the challenges or the struggles, or the other complimentary problems you can solve for your customers on behalf of them to help strengthen that connection they have with your brand.David:And I think what we're going to see is that, we're going to see a lot less mass trends, I guess, in a sense or mass tactics in the sense that brands that are going to be successful are the ones that are going to focus on building a community that is tight-knit has a very meaningful value prop for the members of that community. And ultimately places a little bit more emphasis on lifetime value and holding onto the customers that they have and building a better relationship with them versus turn and burn customer acquisition bring them in, make a sale, move on to the next.David:And so, we're really excited about that because we have a lot of the ingredients necessary to build a meaningful community and we have to do some ideation on this idea of providing more value than we're looking to extract, but it's a new set of challenges and one that I think is a little bit more fun because you're becoming a better partner to your community and keeping hold of that and looking for ways to solve other problems for them and make your brand more appealing and one that they want to connect with on a deeper level. And that's really fun, and so we're excited about that.Stephanie:Yeah. That gets back to the whole idea of long-term thinking. And yeah, I think the companies that'll rise above the rest, especially with so many coming out right now, we're going to be the ones who think longer-term like that. Think how to build that community and really engage your customers. That's not just driven on that quick conversion.David:Exactly. Yeah. And if you look at the mega brands out there right now that are being successful, they're looking at that exact equation, obviously in a different way than we are, but you see brands like Peloton and Lululemon's acquisition of Mirror, they're looking to check a series of boxes, whether it's vertically integrating owning the hardware, developing a reoccurring revenue model. All these things that compliment and go hand in hand with a tight-knit community of consumers that are truly committed to you as a brand.David:Yeah. I think literally Lululemon's one of the most amazing examples because they do such a good job of developing a community, creating these ambassador programs towards, there's one up here on main street, you walk into a store and you look around and the imagery they use our local ambassadors. You look up on the wall and you see your friends up there and it's like, "Wow, one, I didn't know they were in a massive, that's cool." But also to be that smart to actually integrate local ambassadors into their communication and retail is just such a cool thing and makes the brand feel truly invested in this area [inaudible] do that-Stephanie:Yeah. I didn't know they did that. That's really cool.David:Yeah. And so they're all in on the community thing, and I think this acquisition they made of this mirror product is a great way to continue to facilitate that at scale. And it'll be really cool, not really case study, but brand to follow over the next couple of years and see how they continue to evolve because they truly are the best in the biz.Stephanie:Yes. I agree. All right. Well, let's shift over to the lightning round, brought to you by Salesforce Commerce Cloud. This is where I'm going to ask a question and you have a minute or less to answer. Are you ready to go, David. All right.David:All right. [inaudible] this might be tough.Stephanie:I've done a done, I'll have to cut you off.David:Yeah. Cut me off. Don't be shy.Stephanie:All right. What's up next on your Netflix queue?David:Oh, Netflix queue. I don't know the name of it, but there's a film series about the Formula One circuit that has been recommended to me and I wish I could remember the name, but it follows some of the drivers Formula One and it's supposed to be really, really good. So-Stephanie:Drive to Survive.David:That might be it. I think you're right. It saved in our account, which is very helpful. Thank you Netflix. That's the one where we're super psyched to see next.Stephanie:Right. That sounds cool. Yeah. I think someone on our team actually recommended that as well. And I think they told me to watch it from a business perspective. I'm not really sure why. I need to check it out.David:Wow. Well, you have to let me know what you think.Stephanie:Yes. What's up next on your travel destinations when we can get out into the world and travel again?David:Man, that sounds so nice. Doesn't it?Stephanie:I know. That's why I asked it.David:Yeah. My wife and I have been talking about... And we originally were going to do it for a honeymoon, but things didn't work out the way we want it to at that trip, but we still have not skied in Japan. And that is on our list for when things settle down, is to go and Japan such an amazing place and it's such a great culture that we're super excited to experience that a little more in depth than my business trips have allowed. And you would also get an incredible amount of snow. So this seems quite good as well.Stephanie:Yeah. Well, that sounds really nice. And then you can go and hang out in the hot bath with this monkeys. Have you seen that?David:I have seen that. I think my wife might be more excited for that than she is the actual skiing.Stephanie:Oh, I'll go with her then.David:Yeah.Stephanie:I went to Japan and I missed that because we weren't in the right area and that's very sad. I'm like, "How fun would it be to take a bath monkeys?" I don't know. Maybe it's a tourist trap, but either way I want to try it.David:Yeah. It sounds pretty entertaining.Stephanie:Yeah. What one thing do you not understand today that you wish you did?David:Oh, man. I mean, so much. It's a good question. Well, here now, I'm getting ready to take the next level of avalanche certification and understanding how avalanches work so that we can ski and travel through the back country safely. I have some training on that, but there's a lot more that I don't understand. And so that is fresh on my mind as the snow is starting to fall and I'm excited to continue my education on understanding snow pops and risk assessment and making sure that we can [inaudible] snow, but do it safely.Stephanie:I mean, that's a good one. And that is a unique answer. No one else has said that so far. So David-David:Thank you.Stephanie:All right. And then the last one, what one thing will have the biggest impact on ecommerce in the next year?David:I mean, the thing that comes to mind feels a little bit like a cop out just because it's been so talked about, but I think 5G is really hard to ignore and when that fully rolls out the mobile trends that we're seeing are going to become even more important and pointed. So, it's going to put so much more emphasis on the computer you carry in your pocket rather than the one that you sit in front of it at the desk. We and a lot of other brands are still working on how do you crack that device in a way as meaningful as it could be in maximizing the value to the business that comes from a mobile device. So, I think that's going to continue to become more and more important and it's a tough one to solve.Stephanie:That's a good answer. Or it's not a cop out because no one else has said that so far. I thought you were going to say COVID-David:Oh, right.Stephanie:And then I was going to be like, "No. [inaudible 00:51:09]." So-David:No. I didn't think of that. It's the new normal, I guess.Stephanie:I'm glad. Yeah. Exactly. All right, David. Well, thank you so much for coming on the show. Where can people find out more about you and POC?David:Yeah. So, come find out more about us at pocsports.com. Can learn more about our product offering, our amazing roster of athletes and the things that are important to us and want to moment just to thank the amazing team of people, not just with marketing but everybody here involved with POC. Like I mentioned, they are as committed as anyone can be to why we exist and that permeates through our business and so many different ways on a consistent basis. And the people here and the talent that they bring and the drive and passion that they bring truly is what makes us an amazing organization. So, would rather say, thank you to them I guess than promote myself, if that option is okay.Stephanie:That option is okay. That sounds great. Thanks so much, David. Yeah. It's been great.David:Yeah. I appreciate it, Stephanie. And great to speak with you.

In this episode, Holy Cross professor Stephanie Yuhl reconnects with friend and former student Meg Griffiths '04.  They reminisce about Meg's days on campus, and reflect upon the many ways that the Holy Cross Mission and its pursuit of social justice is evident throughout Meg's life and career. Interview originally recorded on July 31, 2020.  Due to the ongoing effects of the pandemic, all interviews in season 2 are recorded remotely. --- Meg: I think people who come to the dialogue table… they come because they’re in touch with something that means a lot to them, and they care enough to show up and listen and try to muddle through with people who they know occupy different positions.  And to me, that’s a sign of hope in and of itself: that people are willing to come to the table. And that they have a shared commitment to making some kind of change, making their community better, making space for more voices and rehumanizing the “other.” Maura: Welcome to Mission-Driven, where we speak with alumni who are leveraging their Holy Cross education to make a meaningful difference in the world around them. I’m your host, Maura Sweeney ‘07, Director of Alumni Career Development at Holy Cross.  I’m delighted to welcome you to today’s show. Maura: In this episode we hear from Meg Griffiths from the class of 2004.  Meg can be described as an educator, space maker, practitioner of dialogue, crafter of questions, and human can opener.  Ever since graduating from Holy Cross, Meg has pursued mission-focused work. After starting her career with the Jesuit Volunteers Corps in New Orleans, her journey has evolved to include work in the nonprofit sector and higher education. Today, she works for Essential Partners, an organization who partners with communities and organizations around the globe, equipping them to navigate the values, beliefs and identities that are essential to them.  Her work showcases the importance of dialogue and connection in order to build trust and support mutual understanding among diverse groups of people.  Stephanie Yuhl, Professor of History, Gender, Sexuality, & Women's Studies, and Peace and Conflict Studies, reconnects with Meg to speak about her life and career.  Their conversation is filled with mutual admiration and respect, stemming from Meg’s time as a student at Holy Cross.  The importance of living the Holy Cross Mission is interwoven throughout the conversation. Despite coming to Holy Cross not knowing what a Jesuit was, Meg has lived a life devoted to the Jesuit values of social justice ever since. Stephanie: Hi, Megan, it's Stephanie. Meg: Hi, Stephanie. It's Meg. Stephanie: How are you doing Meg? I'm so excited that we get this chance to spend some time together and to talk about interesting things related to you and Holy Cross. I have to say, whenever I think of students that to me, have really lived out the mission, you see the T-shirts at Holy Cross that say Live the Mission, and I think that certain people actually really do that and you're always at the top of the list of that, so thanks for sharing your time with us today. Meg: Thank you, Stephanie. When I think about my Holy Cross experience, you are one of the people that regularly comes to mind. So, this is a pure joy to have some Zoom time with you these days in this weird, strange time we're in. Stephanie: It is and hopefully the listeners won't be bored with our mutual admiration society that we're having. Let's get started and let's talk about Holy Cross and you and then, we'll move into your life and career. Tell me why did you choose Holy Cross? What was it about the school that attracted you and how did you move through Holy Cross during your time there? Meg: Yeah. So, I was looking at colleges in the late '90s but before I actually stumbled into Holy Cross, this glossy, beautiful materials that came my way in the old school snail mail, my sister was looking at colleges and she's a couple years older than me. We are very different people in all kinds of ways. My parents had taken my sister to do a New England college tour and Julie came home, very uninterested in Holy Cross and my mom said to me, "Megan, I found the perfect college for you, because your sister is not interested." So, it was sort of planted in the back of my head, before I actively started looking at colleges and I just loved it when I stepped on campus. Meg: I think a lot of Holy Cross students say this, they have this experience of sort of feeling something when they come to campus. My mom said she could read it all over my face, but it really sort of met a lot of what I was looking for in a school at the time, which is a small liberal arts Catholic school. I didn't know what a Jesuit was yet but I was Catholic educated my whole life and that felt familiar in a good way and in a challenging way. Yeah, I landed here in 2000 as a wee freshman, and took me a little while to find my sort of academic home and you, Stephanie, were a big part of that. I meandered through all of my distribution requirements and learned that I wasn't a disciplinary thinker but a multi-disciplinary thinker. Meg: Got a chance to design my own American Studies major before that was a thing on campus, and you Stephanie, were wise enough really, to say yes to being my advisor for that- Stephanie: It was wise because then we got to be friends, and you did your senior thesis on Child's Play, which I think is really interesting and I think it reveals a lot about you and the way that your brain works. Can you talk about that a little bit, explain what that thesis was about, if you can recall? Meg: Yes, I can recall. I can recall sitting in the library at a giant table every Friday writing it, my senior year. I was really interested in gender. I was also a women's studies concentrator before it was women and gender studies and then, material culture, and so, I studied how doll play and child rearing manuals sort of told a story about gender and the role of women in early America and how girls were socialized to grow up to be mothers and caretakers, through the use of dolls and doll play. So, it's really interesting, kind of nerdy but lovely research. It was sort of the bringing together of all of the disciplines of my American Studies major and my interest in sort of gender, and culture. Stephanie: Yeah, and also, I think creativity, right? The idea of looking at something and you see something extensible in that, a doll but then, being able to read and interpret more deeply into it and try to think about what are the influences and impacts that this artifact could have? I think that that is in a lot of ways really connected to some of the work that you do about seeing things one way and then trying to shift one's angle of vision to see it another way to unpack its power. So, it might look like doll play, but I think it was really indicative of future trajectories, perhaps. Meg: I love that. Stephanie: So you mentioned that you didn't even know what a Jesuit was and then, your biography really kind of spent a lot of time in that Jesuit social justice space. So, can you talk a little bit about ... and that's what we would stay around mission, right, around how you're formation at Holy Cross, what are the sort of the things that you think are part of your Jesuit education at Holy Cross, and then we can talk about how you then put those into action after graduation? Meg: Yeah, I love that you brought up the Live the Mission T-shirts, because I was an orientation leader who wore that T-shirt many summer and I'm a little bit of a mission statement nerd, because I just love the way that institutions and communities and even people can take an opportunity to name explicitly what they're about and what they aspire to be. So, I think they're both aspirational and descriptive. The Holy Cross mission, I stepped into it in a variety of ways. I mean, my experience as a student is that you can't go to Holy Cross and not be steeped in mission, but I understand other people have different experiences of that. Meg: For me, I saw it everywhere I looked, and I sought it out also. So, I got involved in the chaplains office, pretty early on in retreats, and in singing in liturgical choir, and sort of embracing the social justice mission of Jesuit education and formation through Pax Christi, and going to the School of the Americas protest and participating in the Mexico Immersion Program and SPUD. Really, seeing the ways that a faith doing justice was a huge part of the college's larger mission and I also just ... I think, part of what I loved about specifically, the Holy Cross mission statement was that it was full of questions and when we talk about what I do now, this might become even more clear to people but I'm sort of all about questions. Meg: I love the ways in which a question can invite us into, again, aspiration and also possibility, and deep personal reflection at an institutional level, sort of organizational reflection on again, who we want to be and how we want to be in the world. The Holy Cross mission statement asks these super powerful questions like what is the moral character of teaching and learning and what are our obligations to one another? What's our special responsibility to the world's poor and powerless? How do we find meaning in life and history? Meg: These are what I have always called the big important questions and I love the way that my academic experience sort of mirrored that more spiritual formation in wading into those big questions and finding the nuance and complexity that comes through sustained engagement with those kinds of questions. There's no simple answers to be found here and I love that. Even though I'm someone who really likes clarity and planning and a clear path, there's a big part of me that also knows, we need to wrestle with the complexity and the gray areas of what it means to be human. So, those are the parts of the mission statement and the way that the mission was lived in my experience that really captivated my imagination. Stephanie: That's awesome and that notion of patience and ambiguity, which is also in the mission is a wonderful thing and it's hard for type A organizers, like yourself and myself, sometimes to sit in that space but I think that that's really probably where we're most human, right? Particularly today in our really Balkanized political discourse, it's important to try to find these spaces of more nuanced. So, let's talk about that a little bit, so you come to the college, you find your way, you figure, you learn what a Jesuit might be, you live the mission, wear a T-shirt and then you graduate, right? With this thesis in Child's Play where everyone is banging on your door to hire you to do something with Child's Play because they don't know that Child's Play is not a play, it's very serious. Meg: I think that was the subtitle of my thesis. Stephanie: It was. This is no joke. I think it's serious- Meg: Something about seriousness of ... Yeah, anyways, yes. Stephanie: Exactly. So, tell me a little bit about ... I know right after college, you joined the Jesuit Volunteer Corps, right? Meg: Mm-hmm (affirmative). Stephanie: And went to New Orleans. Meg: Yeah. Stephanie: Tell me a little bit about that decision and how this question driven impulse that you have, played out in that space. The kind of work you did there, and how maybe your sense of your own personal mission started to shift a little bit in that time. Meg: Yeah, so I served in New Orleans in 2004 to 2005. I served at a domestic violence shelter. We had a transitional shelter and an emergency shelter. My work there involved being a part of the life of the shelter, of the residential life of our clients and guests. I dropped into a culture that could not have been more different than my suburban New Jersey Catholic upbringing, although New Orleans is very Catholic, but sort of my sheltered, very white suburban, middle class upbringing. For me, that was a transformative year in terms of coming to see the lived realities of some of the things that I had studied at Holy Cross. So, I took great courses, like social ethics with Professor Mary Hobgood, and liberation theology with Jim Nickoloff. Meg: I had studied ... and also in my local volunteering over the four years that I was in Worcester, obviously, coming face to face with the realities of injustice and poverty and violence, and sort of had this sort of charity orientation. Definitely, Holy Cross moved me into a conceptualization of justice as a really important aim, more so than charity. They go together but really, that more of my activism sort of bloomed as a Holy Cross student. It was entirely different to move to a city I've never lived in before, worked in a shelter, live in intentional community with six other humans, doing all kinds of work in the city, and tried to live in some shape of solidarity, which is not really possible in some ways, because I was bringing all my privilege and my social network of support with me. Meg: I remember feeling like I saw a different side of the world for the first time, that I really was face to face with three dimensional humans, who were experiencing these things that were really sort of more theoretical in my head at the time, oppression and discrimination, and violence, and classism, and sexism, and heterosexism and all the isms. Yet, New Orleans is this amazing, cultural, rich, historic place that is so much an example of finding joy and having resilience in the face of so many difficulties. Of course, I left New Orleans, three weeks before Hurricane Katrina hit the Gulf Coast, and never was that clear, that sense of resilience and hope and richness of community than when I returned to New Orleans, about 10 months after Katrina hit to move back. Stephanie: Let's talk a little bit about that, because that was a really interesting ... an interesting move for you, I think. They joke that JVC graduates are ruined for life, right? That sort of tagline and I think a lot of our students would find it interesting and helpful, frankly, who also choose this path of service as a postgraduate moment. After that, sometimes they feel a little stuck about what next, right? Because you've just had this really intense experience, an experience in which hopefully, you've made some kind of impact but really, mostly it has an impact on the server, as we know, around that quest around justice and charity models, right? Stephanie: You opted to come back to New Orleans, right, to go back to New Orleans and the listeners might not know this, but Megan, Meg Griffiths was a member of the CIA and I think you should explain that, because I think it will surprise people that you are a CIA member. Do you want to explain that Megan and what called you back to New Orleans? Meg: Yeah. Yeah. So, I had moved up to Milwaukee. I was serving at Marquette University, an internship in their university ministry office, so that's where I went when I left and that's where I was when Katrina hit. I didn't have a television in my apartment. I was living in a residence hall. I just come off of a year of simple living. I do not bring a lot with me to Milwaukee. As the news of Katrina was sort of coming up to Milwaukee, I was really not as in tune with what was happening as I would have been if I had a television and sort of made a point to be following the news. Simpler times back then. I quickly started checking in with some people who I knew who were in New Orleans, and it became clear that it was being taken increasingly seriously, as Katrina was approaching. Meg: So, I think that the fact that I had been a resident of that city three weeks before Katrina hit, I mean, I just ... it felt like home still, as much as a place you've lived for 11 months, can feel like home but- Stephanie: Very intense 11 months, so that makes it more home, right? Meg: Yes, and I just ... the only way I could explain it is I felt like I was having the experience that my heart was still in New Orleans and was breaking for this beloved city and its beautiful humans. So, I made my way down several times that year when I was serving at Marquette. I brought students, I went down and met up with other JVs and at the end of my internship, I didn't really have a plan as to what was next. My supervisor at the time, at Marquette who is Jocelyn, she was the liturgist there, she decided she was taking a leave of absence and going to move to post Katrina New Orleans because she felt so called to do so. Meg: I remember so clearly that she asked me straight out, "If I do this, will you come with me?" Without even thinking, I said yes. That is a moment where I felt so deeply certain about the word yes, that I didn't even have time to think before it came out of my mouth. Then, I was like, "Oh, no, I just said, Yes. I think I have to do this." Stephanie: Wait a minute the overthinker didn't overthink this. She just responded. That's great. Meg: Yeah. Stephanie: That's a pure yes. Meg: Yeah. Yeah. I mean, it felt like a call. I mean, it was a direct invitation- Stephanie: It was an invitation, literally. Yeah. Meg: So I said yes, not knowing what it meant or how we would pay for anything or what we would do. Another person joined us, a recent alum of Marquette, my dear friend, Stacy now. So, the three of us moved to New Orleans, rented a house started calling ourselves contemplatives in action, i.e. CIA. Stephanie: I love it. Meg: So, we built this fledgling nonprofit to help people ... to help receive short term volunteers into the city. So, our Jesuit high schools and colleges and parishes, and so many others but in particular, we had a connection to this larger Jesuit family, and people wanted to come to New Orleans and help rebuild and stand with the people of New Orleans and accompany people in their moment of pain, and hear their stories and bear witness. So, we created an opportunity that made it easier for people to find their way to do that work by helping place volunteers and connect them with local nonprofits and local community leaders and with the spiritual and religious and cultural history of the city of New Orleans. Meg: It was really hard work. I mean, physically hard labor but also emotionally hard work. I remember, Stacy, my colleague and co-conspirator in the CIA, say, "I came to New Orleans, to lighten other people's burdens and what I didn't realize was that I would wind up carrying them, with them." That's how we help lighten other people's burdens. Stephanie: Right, accompany them. Meg: Yeah, and that weight of living in what was, for many years after I was there, still a city in distress and in disarray, is emotionally difficult to show up every day and be present to that and to be able to leave was a huge privilege. That wasn't my life. It wasn't my community. It wasn't my home. It wasn't my school, that was destroyed and yet it felt like a part of me. I also knew that there was a limit to how much capacity I had to continue to show up. So, I made a commitment of a year of doing that work in community and then, stepped out of that work and into the next thing. Stephanie: Right, and that's, I think, really ... I just want to thank you for sharing that. I think it's really important for people to know that, you can step up and step in and accompany and do your very best and sometimes it feels like failure to step away, but stepping away is also stepping towards something else. It's not always stepping away from. This notion of sharing the suffering and sharing the stress, and sharing the work is something that very few single people can do, right? It's something that many people need to step in and come in and go. So, I think that idea that you were there, you went away and you came back, I mean, that's that kind of push, pull relationship. Stephanie: I think it's important for people, particularly younger folks who might be listening, to recognize that one, you make a commitment to something and you follow through on your commitment and then, it's okay to also make a different commitment. That's also part of the development and you're not abandoning people, you're not quitting. Meg: I mean, for me, it was about how can I find a different way to support this work. So, I think, also like, especially right now, in our world, when there's so much work needed, and so many people joining in the long struggle for racial justice, for the first time, finding your place in the work can be really hard and I think we sometimes ... I'll speak for myself, I think I sometimes think that there's only one way to show up, to be part of the work and the truth is, there are many ways and we are as different, in terms of our gifts and our assets, and our limitations, as you can get in humans. So, noticing what you can do, what serves the work, what sustains you and the work. Meg: Then, being okay with pivoting, when you realize that that's no longer the role that you can play or want to play or is helpful to play. So for me, I moved to Providence, which is where I live now after New Orleans and I took a job in higher ed setting and one of the first things I did was asked if I could start a program to bring students to New Orleans. So, I continued my relationship and my work and in some ways, built a much more sustainable way. My advocacy continues like super- Stephanie: Particularly you singularly doing the work. Meg: Yeah. Stephanie: Something that amplifies and continues. Yeah, the sustainability question. Meg: Yeah. So, I mean, not right now because nobody's going anywhere but up until last January, students were still going on the NOLA immersion trip from my previous institution. I built that program in 2009. It ran for 10 years, and it will come back I hope, when travel is a thing again, because the work in New Orleans also continues. The immediate response and rebuilding was ongoing for many, many years and yet, there's still ongoing work that we can do. Stephanie: Yeah, and I think that's really interesting, Meg to hear you talk about how you can best serve because sometimes we do have these default notions that it needs to look a certain way. I would connect this with the spiritual exercises, right? That idea of you have to find your way, right? Discern your way, not the way that the culture might tell you is the way or what does service look like, what does a simple life have to look like? We bring a lot of baggage to that and the hard work of reflecting on what is my path and being okay with that even if it looks a little counter-cultural, if it looks like someone's leading something or pivoting. Stephanie: I think that has a lot to do with letting go of ego. Did you think that had to do at all with ego, the idea of who you thought you were in that moment and then, recognizing there's another way of using your skills and gifts toward a larger end? Meg: Yeah, I don't know that I would put that language around it at the time but certainly looking back ... I mean, I did have a lot of moments of asking myself, like what am I here for? Am I here for the right reasons? Am I the right person to be doing this work? I mean, the answer wound up always being yes or enough of a not no, to stay. I think there are moments where in my own development and sort of self-actualization we might say in the fancy words, where I would look at people that I admired and try to be more like them. I think it was actually another of my Holy Cross mentors, Kristine Goodwin, who at one point, used this frame of sort of holy envy. Meg: That when we see people who live out values that we share in a particular way, we can have some jealousy around it almost, that like, we want to be as good, quote, unquote, as they are. I think there have been a lot of people in my life that have served as beacons or sort of examples. The challenge is to always stay rooted and figuring out how I can live out my own values in my own way. One of the things that I care really deeply about and how I show up in the world, is with a sense of integrity. For me, that means living in alignment with my values and who I am and who I've been called to be. So that there's an integrated self in that way of the word integrity, that what I say I'm about, I'm about or at least I'm trying real hard to be about it. Meg: The same with the mission statements being both descriptive and aspirational. I think my values are things that I hold dear, and I want to live out and I also have to aspire to because I won't do it perfectly, and I won't always get it right. Stephanie: Well, of course and I love that phrase holy envy, I have to say the reason I went to graduate school was because of holy envy. One of my professors at Georgetown, I wanted his life. I thought it was just remarkable what he was able to do and the impact he had on me as a young person. We're very, very different. Went to really different fields and different personalities. We're still friends and that's right, you find your ... you might have the catalyst, the inspiration. Then, as you emerge and you grow, you find your way, hopefully in it. That back and forth between achieved ... hitting the mark on values and aspiring to living that, I think that's really interesting. Stephanie: Tell me then about how in your life, if you can ... and you have a really rich professional biography, educational biography, activist biography, and we don't have time to go into all of them. So, I want to give you the opportunity to highlight if you can, either a moment or a choice or a career path, that for you, really puts this values in action, where that integrated self has found firm ground, and what kind of ... and how you manifest that in your work. Meg: I'll leave it to you, Stephanie, to ask the big old questions. Stephanie: Sorry, but you got to give me a good one example. I'm just wondering, is it your current work now? Is it navigating higher ed? Is it your work, which I'd love to talk about at one point with the LGBTQ alumni network at Holy Cross, which to me has been so important, so we can get to that unless you want to talk about it now. So, it's really up to you. I mean, I think ... like I said, the beginning of our conversation, you are a person, remarkably. I mean, I admire you so much, Meg. When you talk about being catalyzed by people, and you put me in that list, I need to share with you that one of the great things about teaching at Holy Cross is being catalyzed by your students. I mean, I put you in my list. It's true, though. It is true though and you know that and I would throw your wife Heather in there as well. Stephanie: I mean, you the two of you really live what ... from the outside and someone on the inside feels very real. A real life where you don't run away from the hard stuff and you try to stay true to your moral compass. We need more of that in the world, frankly and so I'm glad you're in it. So, having said that, what's a way that you think that that's succeeded for you? Obviously, never 100% but what do you think what's been a moment where you've been able to make those choices and live the way you seek to live? Meg: Well, thank you for that kind offering. When I think about how I've had to navigate and negotiate what it means to live out my values, I mean, I think what has been the ... one of the pivotal sort of negotiations has been around identity. So, you mentioned my beloved wife, Heather. She's a Holy Cross alum as well. Stephanie: And a former student. Meg: Yes. Although Stephanie can take no credit for the matchmaking directly but- Stephanie: Much to my chagrin. I had each of you in class and yet you didn't even know each other as undergrads, which just breaks my heart. See, fate happens, right? Meg: That's right. Yeah, so I mean, I ... So when I was an undergrad, I didn't believe myself to be anything other than straight. When I started to come to know myself, as at first, not straight, and then later claiming various identities over time, but then, partial to queer, because of its sort of umbrellaness of many things. When I was an undergrad, I imagined myself working in Catholic higher ed for the rest of my life, ideally, Jesuit higher ed. I wanted to ... I'm obsessed with mission and mission statements. I wanted to be the person on a Jesuit campus who helped the community live out their mission, of course. Stephanie: You pointed at it, you'd be fantastic. Meg: I was born and raised Catholic. In many ways, my Catholic faith was nourished in college, which is often, I think, not the case for what happens in terms of spiritual development of many young people but Holy Cross was a place that nourished my spirituality, and gave me an intellectual and theological frame for holding complexity, as I was sort of mentioning earlier. So, I took classes like sexual justice and feminist theology and liberation theology, that helped me make sense of a world in which multiple things can be true at the same time, both in the world and inside of a human. So, when I came to know myself as a queer Catholic, that was a lot to take in. Meg: Also, I felt really prepared in some ways to hold those identities at the same time. There is internal tension there, that is never going to be resolved and it's taught me a lot about embracing paradox or seeming paradox. I think that that process of negotiating my identity and trying to live out my values as a faithful person, and my identity as someone who falls outside of the church's teachings about what is right, quote, unquote, I think is what was part of the path of getting me into the work that I do now, which is the work of helping people hold tensions and manage internal conflict, and sit across from someone else who holds a drastically different opinion, idea, ideology, set of identities, and see them as human still, not in spite of but because of what they bring in terms of their humanity. Stephanie: We're listening to them and taking seriously in. Meg: Yeah, absolutely. Stephanie: This seems to me a good segue to talk about the kind of ... what it is that you do? Sometimes people talk about the language of bringing people to the table and having people, and it is sounds wonderful, but it's hard to understand what that actually looks like and I think about my own struggle right now, given our current climate and as an American historian, and the ways in which history is being bandied about and weaponized, frankly, and I feel like I know certain things. I know certain things to be true and you're telling me correctly, that multiple things can be true at the same time. Talking about how does a community respond to what's going on right now and to me, let's just use the example of Black Lives Matter, to me, this seems like it's not an ambiguous at all, right? Stephanie: You're either stand with Martin Luther King Jr. or you stand with Bull Connor and his dogs and hoses. To me, it feels like that kind of choice. How in the work you do, which I think is so important, because I feel myself getting more and more entrenched and frustrated, how would you bring someone like that to the table with someone who had a different feeling? What are some of the things ... this is very much mission. I mean, how do you do that and I want to ask you another question, what do you call yourself? I mean, I know your title is associate, but are you a teacher? Are you a mentor? Are you a space maker? What do you go? So, those would be ... I want to know more about how this actually works, largely, because I feel like this is a free consultation. Stephanie: I don't need to pay you for your expertise because I feel like I need this. I need this in family conversations, Twitter ... my goodness, the text threads, I need Meg Griffiths and your skillset. So, how do you do that work and what do you call yourself? Meg: Well, first of all, we all need a little Meg Griffiths. I mean- Stephanie: True and we need Meg Griffin's baked goods. The whole other story of your community making baking space but we do need a lot of Meg Griffiths, not just a little. So, how do you do that when we're in this moment, it's hard enough anyways, particularly, this reactive moment we're in right now. Meg: Well, let me start with, who I work with and for and what we do, and then, I'd love to talk about what I call myself and how we're responding to this moment. So, I work with an organization called Essential Partners. We were founded over 30 years ago by family therapists in Cambridge, Massachusetts. These were a group of mostly women who looked at the public debates around, say, abortion that were happening in the 90s and could clearly see patterns of dysfunction in these quote, unquote, conversations on public television between the pro life and pro choice sides of the issue. They said to themselves, "You know, these are patterns we see in family therapy sessions. We are familiar with this dysfunction and what these systems produce. These communication systems. These power dynamics, et cetera." Meg: So, they went to work and started playing around with an approach to dialogue that would begin to bring their tools to the public conversation. So we were founded as Public Conversations Project, about 30 years ago. We had a name change about five years ago to Essential Partners. So, what we've done over the last 30 years is fine tune, adapt, iterate, and evolve an approach to conversation around polarizing issues. So, what we do is we come into communities, organizations, schools, faith communities, nonprofits, anyone who wants us, and they usually call because they're stuck. They're stuck or they've gotten bad news because they got a climate study back that said, things aren't looking so hot or because they've had some sort of acute conflict come up in their community. Meg: They say, we need help. We don't know what to do. We don't know how to get out of these stuck patterns that were in. Stephanie: Even where to start, right? That kind of news is just so shattering if it's not your experience of the institution, but you know that some of your colleagues it is their experience. Meg: Right, right. Stephanie: Even that moment of recognition is huge. Meg: Yeah, that cognitive dissonance of, well, I love this place and this place feels like home and community and family to me, what are you telling the other people don't feel that way? Yeah, and other people are like, "Thank you for putting the data in front of people, because we've been telling you this for a really long time or we haven't been able to say it out loud because of fear of consequences, of naming our experience. So, I mean, we do a lot of different things but we usually start by listening and trying to get a sense of what the real ... what hasn't worked in the past. What people's hopes and concerns are. If they can imagine a preferred future, what would it look like for them and their community? Meg: Then, we do all kinds of things. So, yes, my title is associate. I talk about my work as being a practitioner of dialogue and of facilitation. I am a trainer, I am an educator, I am in accompanier. This work feels like the Venn diagram of everything I've done. It feels like the middle of ministry, which I have a history in working in ministry, education, I've done teaching of various kinds, and still work for justice because I think this is about helping everyone in the community feel heard, valued, understood and understand that they have dignity, and that their community sees them as having the same dignity as everyone else. Meg: So, we work with people to build skills, to try on new ways of speaking and listening and structuring conversation. We build people's capacity to lead and participate in dialogue and we also work with faculty to help them bring dialogue in their classrooms. We bring coaching and consulting support to organizations and leaders. We just try to ... I mean, when it comes down to it, what I think this work is about is helping people see what's possible, because when we're stuck and all we have are bad examples of destructive communication about hard topics, we have lost our sense that anything else is possible. We can't even imagine that I could sit across the table from someone who disagrees with me, and feel heard and understood by that person. Meg: Be able to hear and understand what their experience and how they've come to their beliefs has been. That's what we do. Stephanie: It's such important work. I mean, it is a real crisis, I have to tell you and I feel like in a differently trained way than you, I tried to do that in my classroom and yet, in personal life, things get more complicated and it's really easy to fight or flight, that you either fight the fight and sometimes it doesn't always have to be a fight. It can be a combination but everything feels like a fight these days or flight, which is just shut down. I'm just not going to deal with you. I'm not going to engage and there's a certain amount of ... there's a lot of disservice and violence in that, of negating someone entirely and yet, engaging when another person doesn't have the same skill set, and where my skill set might be really out of training, because of the world we're living in, can be a really, really hard thing. Stephanie: It also seems like it's a hard thing for someone like me, I would say, who's very outcome oriented, right? When I directed Montserrat, one of my colleagues said, "Okay, we need to process these program goals and outcomes all around assessment," right? I said, "Well, we did that, didn't we." She said, "No, we need to have more meetings and more conversation." I'm like, " Ugh, process." So, I discovered, I'm kind of a closet autocrat, that I ... the illusion of democracy but I really just, let's get it done, right? So, I've learned as an adult to slow down and listen and embrace process more. My teenage children might not agree with that but at least in the professionals space, I tried to do that. Stephanie: It's been a challenge for me, and I know that you also are a person who's outcome oriented, action oriented, but you're also a process person. So, what advice would you give us today, who are all having these conversations in our lives, professionally or personally, around this idea of process itself being worthwhile and not just thinking about the win or the outcome? Meg: Yeah. That is- Stephanie: Consultation, free consultation, but it's true and this is mission, right? This is exactly ... when you talk about your Venn diagram, again, I think you're very lucky and I think you've also been really intentional about creating that diagram. Some of it might be luck, but a lot of it is choices and most of us don't necessarily have as integrated of a Venn diagrams as I think you've been able to construct. So, what do you think? How can we do this better? What would you say to folks that want the outcome that weight with the process. Meg: So I mean, my thing is ... I often say this to clients who are like, we got to get to the business. We got, blah, blah, blah. I'm like, "Y'all, this is the work. The process is the work because if we're stuck in destructive patterns, we got to rebuild a different kind of pattern. We have to examine the processes that are getting us stuck and every process is designed to get exactly what it gets." So, if you're going to try and like, be different together, you have to have a different process. For me, I think about naming that with people up front, because we are so outcomes focused, right? People call us because there's a problem, an acute problems. Sometimes a very public problem, sometimes a lawsuit kind of problem. Stephanie: Right. Meg: They want to fix things and I think- Stephanie: Make it go away. Make it go away. Fix it and move on. Meg: Yes and hopefully, people when they call us, they're not trying to just check a box, they're actually trying to change the culture of their organization or their campus and build some new skills so that they don't need to keep bringing us in all the time if they can start to build their capacity to change and shift things themselves. Stephanie: I was thinking that it sounds like the kind of work people and organizations should do before the acute crisis. In other words, you should build your skill set before the crisis, because what I talked to you about was this idea of how do you bring people who are so outcome oriented, think of the process is the work because ... And also how do you do it when it's asymmetrical? Let's say you have the skills of process, but the person on the other end doesn't have the skills? How do you leapfrog them? Meg: Yeah, and so, one of the things that we do organizationally is we have a couple of certain organizational norms and principles. One is, we say, connect before content. So every time we're doing anything, a client call, a workshop, a dialogue, we build the time in to connect as humans before we get down to business. We do that really simply, we might ask a question like, what are you bringing with you into this conversation that it would be helpful for other people to know about as we prepare to like land in this conversation, or tell me about how your morning has been, right? It doesn't have to be so fancy and what we do in every engagement is we try to model a different kind of process. Meg: Bring people into that so that they can see what shifts. So, I'll say, I actually have done some work at Holy Cross, I worked with the chaplains' office with Marybeth Kearns-Barrett, who was trained by us when we were still Public Conversations Project back in the late '90s, as an early adopter of dialogue and we were able to work together to re-imagine the freshmen retreat and I trained a bunch of Holy Cross faculty and students and staff in our facilitation model to prepare to lead that retreat last fall. Marybeth, she took this idea of a connecting question into other work that she was doing on campus, and that she heard from someone who participated in that conversation, that it was the most seen and understood, that community member has ever felt on this campus. Meg: Because they were able to show up and tell a different side of who they are in that space. Because in our work lives, we're often put in boxes of ... and we introduce ourselves, name, rank and serial number, how long we've been here where, all these things that can actually serve to disconnect us rather than connect us because it can highlight our differences or different levels of power and status. When we ask a connecting question that actually invites story or experience, a little bit more of our humanity into the room, and we suddenly see each other in a new way, in a more three dimensional way. The same is true in a deeply divisive polarizing dialogue. Meg: That what we do is we invite people to share a story about something that would help other people understand how they came to their position on an issue. We don't ask people to state their positions. That's a destructive pattern of communication. We know what that looks like when it plays out when all you do is bring a position to the conversation. When you can bring a story, a piece of who you are and then when you can share the values that are underneath that story, you start to get a more complex picture and then, you ask people actually, where have you experienced internal tension on this issue? That is a completely different conversation. Meg: There are infinite, more possibilities for how that conversation can unfold and if we stick to our typical pro and con, or and against position conversations, Stephanie: That's really, really helpful to think about, and it makes me ... I don't think I did this in the class I taught with you but I do this political autobiography assignment that actually, Margaret Post back when she was directing the CBL and Donelan Center really helped me shape and she also does a lot of this kind of service work and scholarship. It's the same thing, I asked my first years to write a political autobiography without any guidance, just like who are you? What do you believe? It's very much a position statement, pro, con and then, through a series of interviews with peers and different reflective exercises and the readings and of course, over the course of the semester or year, if I'm teaching at Montserrat, they rewrite various points of it. Stephanie: It's so interesting, because slowly as trust is built and confidence, and a sense of community, they feel able to share, exactly what we're saying, when you said a piece of themselves. It makes that position so much more legible, and it makes it legible to the peer and the various peers that are reading those autobiographies or having the interviews. I always try to put people that I've ... have a sense of might be oppositional in the conversation, because it's easy to be oppositional on paper but when you're sitting at Cool Beans with a cup of coffee, and I say go to breakfast, have coffee, sit on the hovel, suddenly, I understand Meg, even if I might disagree with her. Stephanie: Suddenly she's going to understand me differently and 201, the students that comment, they love the assignment and again, it's built on the shoulders of other people and their help to me. They comment that, that experience of being with a peer talking about serious value driven questions, and needing to listen because they have to reproduce the conversation, each of them and then reflect on it, as part of the assignment, was the high point, right? That's just like a teeny little bit of what sounds like what you're doing though, that adults need to do that, right? So, these are these young people information and it's underneath this academic umbrella. Stephanie: Then, it's like, okay, your credential, if you've got your BS or your BA go out into the world, you're fully formed now and clearly, we still need that. I need that reminder, in my own life. It's funny, I feel like I can facilitate that a little bit with my students because of my position as professor and they have to do what I say, but am I doing it in my own life in the spaces that that needs doing? Meg: Well, I love that and that is so beautiful, Stephanie because I mean, when we talk about how to bring this work into the classroom, we have a particular approach. It's highly structured and it's structured because we know that that helps people feel safe enough to contribute. There's a sense of certainty about what to expect. They know that there's a container for the conversation to happen inside of and it can hold a lot. The container can hold a lot of emotion, a lot of disagreement, all of those things but you don't have to bring a 90-minute structured dialogue into your classroom, to create the kind of dialogic spirit that you have clearly demonstrated, right? Meg: It can be as simple as helping students, and then also to your point, bringing this out into the world, in our families, in whatever, right? Helping them to ask questions that will invite that deeper experience, that is behind their belief. It's about following our curiosity instead of listening to debate or persuade, right? The intentionality that we bring to our listening and to our asking of questions, we know has a powerful impact on what we hear and how a person responds. So, we come with a genuine curious question. We're going to get a really different response from our interlocutor or conversation partner than if we come with a question that's actually just a suggestion with an inflection point at the end of the sentence, don't you think it would be better if you just did this? Stephanie: Do you mean my mom voice? Yes, I know that, I've heard that once or twice. I always say I'm a better professor than I am a parent. I'm so much more generous and open ended with my students than with my own children. Meg: My God, please. Heather is like, that doesn't sound like a curious question. Stephanie: There's no fun in it. Yeah, I'm not talking ... That is great, I love that she says that. Look, bring your work to home. Usually, it's like your work at the work place and you're like, "Okay, bring it into this conversation." That is too funny. Well, I would like to write my congressional representative, Jim McGovern and suggest that he bring essential partners to Congress, because I think exactly what you're talking about is what we need and we need it frankly on local and state government levels, as well as institutionally what you're talking about, because I really think we are in a crisis and unfortunately, I don't believe that playing to just ... I mean, leadership matters and the tone is set from above in many ways, I believe in a ground up model too. Stephanie: I don't think that necessarily just notions of who's in charge is going to magically change how we have trained ourselves over decades frankly, really, it's not over a few years as a country but over decades to not listen and to not understand because people are angry and frustrated and then shut down. So, it sounds like if you were to describe yourself beyond, you need a new title. The associate does not encapsulate it. It's teacher, it's curiosity generator, it's ... you're a human can opener. You're a maker of space for these things to happen. We need a more- Meg: Crafter of questions and- Stephanie: Crafter of questions, that sounds like Hogwarts. The Crafter of questions and potions. Well, this is such a pleasure and I have to say I'm so glad you do this work, Meg, because we really so desperately need it. It must feel wonderful to do work that you really believe and see, as needed and effective. That's really awesome, so thank you for that. I'm going to shift gears and do you want to say one more thing? Go ahead. Meg: I just want to add, I think sometimes dialogue gets a bad rep because there are so many urgent issues that need action and attention. So, I just want to say that dialogue is a tool, and our approach has, at its heart, a purpose of building and supporting mutual understanding, and it is not going to solve all the world's problems but what it is really good at is building trust, building understanding and building social cohesion in communities that have been sort of torn or harmed in terms of their sense of community, and it can lay a really strong foundation for action, for a community coming to know and understand where its shared values and shared hopes are and then, moving toward that. Stephanie: Again, this is a ... it's a really helpful precondition. A really necessary precondition but I appreciate you saying that because I think, again, as historian of the ... and I think about Martin Luther King Jr. in Alabama, Birmingham and the City Council saying, "Just wait, don't do this now, wait. This isn't the time," and he wrote his piece why we can't wait and the letter from the Birmingham Jail. So, there does come a time when dialogue shuts down, because it's not really dialogue. It's not dialogue of ... sort of you're talking about, which is people on various positions and I'm saying sides because we don't want to be binary, occupying various spaces in the conversation, who are equally equipped to have a true dialogue, as opposed to not equipped. Stephanie: If people refuse to be equipped, and they insist on being equipped or failed to be equipped, then, of course, I understand why it breaks down and people have to act, because you're right, action toward justice is what the process is hopefully leading toward. Meg: Yeah and people have to ... I think people who come to the dialogue table, they come because they're in touch with something that means a lot to them, and they care enough to show up and listen and try to muddle through with people who they know, occupy different positions and to me, that's a sign of hope in and of itself, if people are willing to come to the table and that they have a shared commitment to making some kind of change, making their community better, making space for more voices and re-humanizing the quote, unquote, other and that ... again, process is an outcome. Stephanie: It were, you say, yeah. Meg: The outcome of that is increased trust, increase connection, increased resilience of listening and social cohesion that, as you said, can be a precondition for greater change in terms of structural change or organizational change, or societal- Stephanie: Yeah, absolutely and even an opportunity for decreasing certain kinds of behaviors, right, is also ... plus its increasing capacity, but not just dismissing a person because you think you know their whole bio or of course, that's how they're going to react and I'm sure that in your work, you come up against certain parties in various institutions, when they hear your plan, say, "Well, I'm not going to do that, right. That's not for me." That must be really frustrating because the idea is to build that trust so that, people who need it, who's all of us, that's the other piece, it's not just certain parties need to hear all, all the parties need to hear. Stephanie: I think that that's a really inclusive model. Awesome. That's great work. It's so needed, I want you to come to my house in my next Thanksgiving dinner, Meg and we'll have a consultation. All right, so let's shift gears, because we don't have too much time left, although I could do this all day long. I wish I could. I'm going to do something called speed round for fun. Meg: Okay. Stephanie: My gosh, what is it? Okay, and I'm going to ask you a series of questions and I just want you to answer in whatever way you want. Okay? They're really, really heavy questions. These are heavy questions that are going to shape the future of the world, ready? Favorite vacation spot? Meg: Wellfleet. The Cape. Stephanie: Beautiful. Favorite baked good that you make yourself? Meg: Homemade no knead bread. Stephanie: Favorite dessert that's a dessert, baked good. Of course. It's so funny that I say baked good, I'm immediately thinking chocolate and you say bread. So, favorite dessert, dessert not just bread. Meg: It's the Italian in me. Stephanie: I know. Right. Meg: I don't actually make a lot of desserts but I buy the most delicious brownie from The Vegan. I know, it sounds unbelievable. The Vegan bakery down the street has amazing fudgy chocolatey brownies. Stephanie: Delicious. All right, then that sounds perfect. I like that. My mother was a baker like that. She was like, I don't really bake, but I go to Paris Pastry Bakery and I buy the best stuff in pink boxes. What is one of your favorite places in Worcester, because you also lived here for a while after graduation, what's one of your favorite places in Worcester? Meg: Can I say your house? Stephanie: Yes, you're so sweet. Thank you. More importantly, what's your favorite restaurant in Providence, your current home? Meg: We have a weekly standing Friday night dinner at the Vegetarian Place down the street. It's Garden Grill and we miss them terribly while they were shut down and now, we get takeout usually on Friday night. Stephanie: Nice. Garden Grill in Providence. Excellent. Do you make New Year's resolutions or is it every day resolutions? Meg: I don't usually make a New Year's resolution. I try to reflect on the previous year, around that time of year. I don't really make resolutions. Stephanie: That's good. I think you live resolutions every day. Resolutions are outcome oriented. They're not process oriented anyway, right? Meg: Yeah. Yeah. Stephanie: Maybe what we should make are New Year's process commitments. We need to change that to ... change your title and change that tradition. All right, what about ... real quick back to Holy Cross, what was your favorite dorm that you lived in? Meg: I was the first class to move into what was simply called the apartments, my senior year, now Williams Hall. I was the senior resident director. The first ever in the senior apartments. Stephanie: Did you get a room with a good view of downtown? Meg: I was in the basement, so not the perfect view, but close to the nice balcony- Stephanie: They do. Meg: Yeah. Stephanie: That overlooked Worcester. What about if it's possible back in the early 2000s, your favorite food at Kimball? Meg: Gosh. Stephanie: It's gotten so good. Meg: Probably, froyo with cereal on top. Stephanie: Yeah, I think that's probably still, because that constant open machine of the froyo, yeah. What kind of cereal? Meg: Cinnamon toast crunch or something with sugar- Stephanie: There you go. Excellent and then, what's the best part about being a Holy Cross graduate? What's the best part about being part of this community and I'm going to add, what is something you would like to see more in this community of people? Meg: Well, one of the best things about being an alum is that I got to build the LGBTQ alumni network and meet a bunch of really fabulous and I mean fabulous in all the ways, LGBTQ alums and be part of creating a space where some of our alums who had never stepped foot on campus since they graduated, and had felt really disconnected from the college could reconnect. So, we have a network of hundreds of alums from across many decades and more than a handful of people have made it known to us that they have not had a relationship with the college until this group was founded and recognized and the college was so supportive when we approached them a number of years ago. Meg: Really, the request and encouragement of students at the time from the Abigail Allies now Pride group who wanted to see alums be recognized and organized so that they could see themselves in the alumni community, and that they could have support from alums. So that work has been really meaningful and my colleague, Phil Dardeno, from the class of 2002, has really held that work and steered the ship for the last few years. Stephanie: Wonderfully so and I can attest how important that group is for students. This model of, of being able to move through this place and be true to oneself and have a community that matters, that's wonderful. What would you like to see more from your alum group or from ... what do you what do you hope Holy Cross graduates can bring to the world right now? Meg: Gosh. Stephanie: It's a diverse group of people, so it's so hard. Meg: I know. Stephanie: A hard ask. Meg: Holy Cross alums are doing amazing things in the world and I love how we have Dr. Anthony Fauci out there representing some of what it means to be a Holy Cross alum right now and I'd love to see more storytelling and more ways to bring alums back together. I think the affinity spaces is the future of alumni development and alumni community because I imagine I'm not alone in this. My relationships and connection as a student spanned all four ... well, more than four, graduating classes because I was involved in so much. The idea of coming back for reunion is like, lovely and also, those are not all my people. I missed the people that I saw and had relationships with, that were years ahead and below me. Meg: I would love more opportunities for alumni to gather and now, that must be virtual. Also, for the college to tell the story of more alumni who might be not as famous as Dr. Fauci is and doing really amazing and important work in the world and that's why I love this podcast, but also, I think to amplify and elevate voices of alums who are doing ... who are living their mission and the colleges and then, have opportunities to like hang out together and learn from each other and like rub off on one another a little bit. Stephanie: Exactly, and then, that's that sustainability thing, right, that it fires in sustainable and relationships. That's awesome, Meg. I am so grateful for you, taking the time today to share your story with us and also to share your wisdom around process and relational exchange and hope. Whenever I speak with you, I always leave with a great sense of admiration, love but also such a sense of hope. You're a person who makes things possible and I thank you for that because sometimes this world feels like that ... possibilities feel, they're shutting down. They're literally shut down with isolation, right? It's just really revivifying to spend time with you and I appreciate how well you live the mission. Do you still have your T-shirt, we should have had you wear it. Stephanie: Maybe you have to find an old picture of you in the T-shirt to send ... to post with the podcast, of moving people into the apartments, right? Meg: I'll have to ask Brenda Hounsell-Sullivan, if she has an old orientation photo of me with the Live the Mission. Stephanie: I'm sure she does. I'm so grateful. Thank you so much. I will hopefully come down to Providence and grab some Garden Grill with you and Heather, and my husband Tony soon and keep up all the wonderful work you do. Thank you for being part of the Holy Cross story, Meg. Meg: Thank you for being one of my beacons along the way, Stephanie. Maura: That’s our show!  I hope you enjoyed hearing about just one of the many ways that Holy Cross alumni have been inspired by the mission to be people for and with others.   A special thanks to today’s guests, and everyone at Holy Cross who has contributed to making this podcast a reality. If you, or someone you know, would like to be featured on this podcast, please send us an email at alumnicareers@holycross.edu.  If you like what you hear, then please leave us a review. This podcast is brought to you by the Office of Alumni Relations at The College of the Holy Cross.  You can subscribe for future episodes wherever you find your podcasts. I’m you’re host, Maura Sweeney, and this is Mission-Driven. In the words of St. Ignatius of Loyola, now go forth, and set the world on fire. --- Theme music composed by Scott Holmes, courtesy of freemusicarchive.org.

Haven’t had a chance to listen to our first 50 episodes yet? Never fear, you’ve got time and they’re not going anywhere. In the meantime, we’ve created an epic recap episode to keep you up to date with this ever-changing world. Throughout the first 50 episodes of Up Next in Commerce, we’ve chatted with some of the fastest-growing startups - like Thrive Market and Haus - to the more well-known companies like Puma, Rosetta Stone, Bombas, and HP. Our guests have shared everything from their toughest lessons, to their secrets to success, to the must-know advice for every ecomm leader. And while every company is different and every story unique, over the last 50 episodes, several common themes have emerged. On today’s special episode of Up Next in Commerce, host Stephanie Postles is joined by Albert Chou, the VP of Operations at Mission.org, to dive into some of these top trends.The two discuss the supply chain shakeups companies have had to face this year, and they do a deep dive into the world of influencers and how brands can work with them in a way that leads to lasting ROI. Plus, they look into their crystal balls to try to predict how DTC companies will work with and compete against Amazon, debate on how voice search will impact shopping, and discuss what the future of shoppable worlds might look like. Main Takeaways:Supply Chain Shakeups: Everyone is competing against the hard-to-match expectations set by Amazon — but it’s not all about fast shipping. Processing returns effectively and managing every step of the supply chain so you are left with margins that actually allow you to grow are the main areas that all retailers are, and will continue to be, focused on. I’ll Take One Order of Influencers: Because influencer marketing has become so in demand, there are more strategies than ever to try to get the most ROI out of influencers. What is likely to happen in the future is the creation of a marketplace where brands can buy verified influencers, who are themselves driving the demand for more upfront payment.  Make It Worth It: Building an omnichannel strategy is about more than just offering a brick and mortar location for people to buy your products. Today’s shoppers are looking for experiences that are memorable and entertaining. But it’s important that while brands create those memorable experiences, they don’t forget that little goal of converting potential customers into real buyers.Turning Virtual Into Reality: Shoppable video and the increased offerings of digital products is going to set the stage for future commerce. The next generation is already using real cash to buy virtual products for their avatars in various games. In years to come, not only will you have the option for your avatar to have that virtual product, the real-life version will be offered in tandem for the user behind the screen.For an in-depth look at this episode, check out the full transcript below. Quotes have been edited for clarity and length.---Up Next in Commerce is brought to you by Salesforce Commerce Cloud. Respond quickly to changing customer needs with flexible Ecommerce connected to marketing, sales, and service. Deliver intelligent commerce experiences your customers can trust, across every channel. Together, we’re ready for what’s next in commerce. Learn more at salesforce.com/commerce---Transcript:Stephanie:Hey everyone, and welcome back to Up Next in Commerce. This is your host, Stephanie Postles, co-founder of mission.org. Today, it's a new and interesting episode where I have our VP of ops, Albert Chou on the show, where we're going to go through the previous 50 episodes and talk about highlights, and then talk about future trends that maybe no one has talked about on the show so far. Albert, welcome.Albert:Yeah, thanks for having me. But to be clear, we're not going to go by the 50 episodes one by one because-Stephanie:We're doing one by one.Albert:No, that's terrible. We can't do it. Cannot do it.Stephanie:So, Albert, tell our listeners why did I invite you on the show?Albert:Well, I do have my own ecommerce business, www.[inaudible 00:00:41].com, I've also helped out on a couple others. The biggest one got to 10 million a year. And I worked for an ecommerce startup. One of the co-founders was a guest on the show AddShoppers. So, been working in the game of ecommerce probably since 2016 and still operating today, so learned from painful mistakes, as well as seeing other people have great success.Stephanie:Yeah, you always have some really good feedback and comments on our prep docs. Our amazing producer, Hilary, will put together an awesome prep doc for every episode for me, and then you come in along with all your other job responsibilities at mission, with the VP of ops, you do everything here, but you also come in and add some good questions and comments, and that's why I thought it would be fun to bring you on. So, thanks for hopping on here with me.Albert:Yeah, let's do it.Stephanie:So, to start, I thought we could kind of go through just some high level trends, because through all the episodes that I've had and all the guests we've had on the show so far, there's actually quite a bit of similarities that I heard. And starting with the first one, I think talking about supply chains is really interesting, because so many of the guests who've come on have talked about the shake up in supply chains that they've seen and how they're kind of pivoting and what they're experiencing, and I think that might be a good place to start.Albert:Well, when they talk about supply chain, everyone's competing against what Amazon has created, right? Amazon has created this expectation that you can get what you want, when you want it pretty darn fast. And so if you're any direct consumer brand, or any brand out there, if you're a retailer, that's what's becoming the now norm, right? Can you send it to your customer really fast, and can you take it back? That's like probably the most painful part of ecommerce is the fact that you do have a percentage of tolerance for returns. So, the tighter your supply chain is, the more margins you can create in the process, the more able you can take a return without losing everything. So, it makes total sense that every business is trying to figure this out, how to get closer to the consumer, how to make things closer to the customer, how to make sure that they can take back whatever is being sent back. So, it's just matching what the new customer expectation is.Stephanie:Yeah. I think it was also very interesting, talking to the ShipBob guy where he was talking about how you can basically tap into different fulfillment centers by using them, whereas before, everything with COVID, a lot of people actually were shipping all the way across the country and not really looking at maybe location based ordering. Maybe some people were, but I found that kind of a good shake up that now people are starting to think about how to do things more efficiently and how also not just to rely on one supply chain, because a lot of them maybe are going out of business right now, a lot of the warehouses are having issues, there's a lot of inventory issues. So, it's good to have not all your eggs in one basket.Albert:So, it's not just that. So, there's companies out there that are investing into logistics infrastructure specifically for other people to share. So, similar to ShipBob, there's other competitors in that field. But it goes further than that. If you take a look at some of the publicly traded companies, one of the larger ecommerce platforms, they have invested heavily in infrastructure and warehousing. I know that ChannelAdvisor did the same exact thing. They literally bought a warehousing logistics company. And ChannelAdvisor, for the longest time, has been a company that helps you as a merchant, list your products across the different marketplaces. So, if Stephanie's t-shirt company wants to list their product across Amazon, they want to list it across Rakuten, they want to list it across eBay, and maybe some others, she would still have to ship and fulfill from her own store.Albert:Now, why did ChannelAdvisor build that tool so you can list one product and get it plugged in everywhere? So, why did they invest in all these warehousing companies? Now, it hasn't come to full service yet but you can kind of see it down the road like the supply chain is where the innovation is going to occur. And I think you're going to continue to see that, you're going to see more entrance in it, and it's just non stop, that race will never stop. Basically, a customer can never get something fast enough. You know what I mean? There's always going to be this push to get it there faster.Stephanie:Yeah. It's also interesting hearing about certain companies trying to compete with shipping models against Amazon and trying to have one in two day shipping. It feels like such a hard thing to create from scratch now, but if you can figure that out, you're going to win.Albert:So, I don't know if you know this, Steph. I've also sold through FBA Amazon.Stephanie:I think you told me that?Albert:Do you know [crosstalk 00:05:37]?Stephanie:What did you sell, first of all?Albert:It was an adult card game.Stephanie:I don't want to hear anymore. This is a kid friendly show.Albert:It was not kid friendly. But how it worked is, so I got my order in China, and I had 5,000 pieces, literally shipped it to an FBA Center in New Jersey, never touched the product, and then Amazon automatically redistributed it across as its fulfillment network. And I would get updates like, "Oh, we're moving two boxes to Texas." "Why?" Because we predict, in Texas, someone will buy this, and therefore by moving it closer to the customer, we can reduce the shipping with our internal [crosstalk 00:06:20]."Stephanie:Do you have an influence over that prediction model.Albert:No.Stephanie:Because now more than ever, I'm like, how can anyone predict anything? I mean, there was a really good quote about like, should we be preparing for more people to buy Inkjet printers because they're all working from home, or extra freezers to prepare for the worst? It feels like there's no way to predict for that, so how do they even know that there's a couple in Texas who might want that?Albert:So, add to cart. I think add to cart is what they're doing, right? They're looking at how many people are adding to cart and then they're also looking at the percentage of conversion over time of people who do add to cart. So, if you see a bunch of cart adds for this product or a bunch of search volume increasing for a product in a specific area, you can automatically assume that that product is going to be in demand in that area. They've probably gotten it down to a super exact science.Stephanie:Yeah, I'm not going to question them. I'm sure they got it.Albert:Yeah. And since they're always moving products within their own fulfillment network everywhere, they see that there's a probability that this is going to happen, they just move it closer to you so that when they finally rely on last mile logistics, they've got it as close as possible so that they don't have to pay so much.Stephanie:Yeah, that makes sense. All right. So, the next one I want to kind of move into is influencers. So, first, we did a survey of our audience and a lot of people wanted to hear about influencers. How do I use influencers? What's a good way to actually get a good ROI on it? And a lot of our guests actually mentioned influencers as well. Some people were trying it out and were like, "I don't actually know if this is even working." Other people were having great success but were trying different models. So, I don't know if you've listened to the fancy.com CEO, Greg Spillane episode.Albert:I did.Stephanie:Okay. Well, first of all, that guy's a badass. I mean, making that company his stories. Like did you hear about how he went into a warehouse or a storage locker and found a bunch of credit cards that the founders were giving away with like $1,000 on it, and they were just giving it away to influencers just to try and get them to use fancy.com? Did you hear some of the stories that he was going through about what he experienced when coming into the company to try and turn it around?Albert:I mean, it's the classic, right? It's the classic problem in marketing, right? You're pretty sure some of it is going to work, some people say it's up to half, you just don't know which half, right? And so you're just blowing money trying to get more movement, but I get what they were originally trying to do makes total sense. I mean, you read about the stories of businesses like Gymshark, which built their whole business model off of influencers, and I think they just got a private equity valuation into the billions, so everyone wants to jump on that train.Albert:The problem is influencers themselves have created this marketplace, right? So, if you claim you're an influencer, and you have hundreds of thousands of followers on Instagram, now influencers, they don't want to work on commission, they want to work on upfront fees. So, there's this new network which you're now going to see tools come into place of helping merchants buy influence. And so that's the next wave, right? Because I mean, there's a lot of influencers that are frauds or they have no influence on their audience whatsoever, they just have a big Instagram following for whatever reason.Stephanie:Yeah. They just [crosstalk 00:09:30].Albert:That's why the merchants are so frustrated.Stephanie:Oh, yeah. I mean, it's hard to know. You can see someone with a million followers, and something that I saw that was actually a good reminder for anyone with a small business was they're talking about how you can see if those followers have an intent to buy. So, if you have some influencer on there and they're showcasing some purse, or some lipstick, or whatever it might be, and the people in the comments are like, "Oh cute," or, "Pretty" or just liking it, they actually don't have followers who have an intent to buy. Versus you might see more micro influencers, like people that follow from around the area or something, and the people in those comments are like, "Where do I get that jacket from?" Like, "Please link up your shirt."Stephanie:And those are the kind of influences you want to go after because you actually know that if you're in front of their audience, they're ready to buy because they trust that person, which seems like it's kind of shifting, whereas before it was like just get the big name, the big followers, and now it's more like, "Let's make sure we get an ROI. How do we make sure to track this stuff and see some good conversions from it?"Albert:Yeah. I mean, you don't know what you don't know, so all you're looking at is what you assume is a big audience. And so that's the biggest misconception in social media, it doesn't determine their purchasing behaviors. It's just, "I like this person because I think she looks good, or I think he looks good, or I think he's funny. I'm not going to buy anything.Stephanie:Yeah, I can definitely see tools coming out soon, or maybe they're already out in the world, showing like here are kind of the demographics of this person's followers. So, you can sign up with an influencer and also see the income level, the job title, so you know that what you're getting with that influencer is going to have good results because you can see the profile of their followers.Albert:So, interesting, right? Platforms now that are creating marketplaces of influencers. So, I'll name one. We have not had their CEO on the show, but grin.co, you should join the show.Stephanie:[crosstalk] here.Albert:Yeah. GRIN is pretty fascinating, because they've built this marketplace where you as a merchant can then log in and you can see all the influencers, you can search by category. Let's say I want surfing, or you want food, or you want outdoor, whatever it is you want, it'll pull up a list of influencers and then it'll show the basic vanity metrics. But it also has ratings of probability of sale, because they've already maybe done a campaign for another brand, so you as a brand kind of see those numbers. Now, the problem always is, as a consumer is, you kind of always get drawn to the big numbers, right? So, you'll see like, let's say, the superstar TikToker, girl Charli D'Amelio. How do you pronounce her last name? D'Amelio?Stephanie:I don't know, and I'm surprised you know anyone on TikTok.Albert:But Charli D'Amelio, you'll see her name and it'll show you significant likelihood to influence dollars, it'll be significant, right? But then as a brand, you have to determine can you afford her, because she doesn't tweet or TikTok for you for nothing, right? It'll be hilarious. It'll say her agency, and of course, she's repped by a huge agency. So, that's where even tools like that, the problem is, let's say, the signal to noise ratio is still overwhelmingly noise and the ones that have tremendous signal, well, the problem is you can't afford it. So, I think the tools have to try to figure out by budget, almost, like how much ROI are you going to get per $1,000 of spend or something like that? That's probably going to be the next wave of measurement.Stephanie:Yeah, I agree. I mean, I think also the platforms are trying to catch up to be able to actually attribute sales to these influencers. I know TikTok is trying to do that right now. Instagram's been trying to do that, but I think they are still implementing a lot of features to actually allow the influencers to get paid. So, I think with that, you'll see a whole new wave of new influencers and micro influencers as well because now they can actually get paid.Stephanie:I mean, I saw someone, they were talking about some... I think it was some coffee mug or, I don't know, a cup or something on TikTok, and it was on Amazon, but didn't have any links or anything, and it sold out on Amazon because this one girl was talking about the functionality of it and how much she liked it, and people were like, "Oh, how do I buy through your link? I want to make sure you get a cut of it." And she was like, "I don't need that. I just review stuff because it's fun." And so it's interesting seeing how you have influencers who really do care about that attribution and won't work without it versus the people who maybe are big influencers but aren't actually looking for that, at least not right off the bat, or maybe because there's friction right now, with setting up that model.Albert:Well, I think the bigger you get as an influencer, the more you could charge for your time than results. So, if you're a superstar, like, let's go with professional athletes, the original influencers, right? If you're LeBron James, you're Michael Jordan and someone wants to buy your name, you just charge them for the name. Like you're like, "I don't know if you'll get $1 of sales, I'm just telling you right now that I'm not repping your product unless you pay me this much money." Right?Albert:So, it's still this push and pull where brands want all this information, they want to know your audience, they want to know all that stuff, and then influencers themselves are getting so big. Like, we're reading about how these people on TikTok, kids, I call them kids, I'm old, but they're making 100 grand a month, and that's considered an average influencer. What are talking about? 100 grand a month to make TikTok dance videos, and yeah. So, I can see a brand wanting to be like, "Well, how much will I get for sales," and I can just see how tough it is when the kid on the other end says, "Well, I won't TikTok dance for you for under 100,000."Stephanie:I just read that the next generation is getting paid more than ever right now, not just for being influencers but just for a lot of things. They're demanding higher payment than any other generation before them. That's good, good intense though.Albert:Yeah. Listen, ask for whatever you want. If you can get it, you might as well ask for it. Why not?Stephanie:Very, very true. So, I think the high level summary for that one then it's just that most brands should be exploring influencers in your market, but also making sure that you're setting up the ROI and tracking it correctly, and maybe looking for those new tools that are coming out or that are already out to make sure that wherever you're devoting your budget to you actually can track it, where in the past maybe it wasn't as required by your company or yourself to have that many metrics behind it, but now you actually can, so I think it's worthwhile.Albert:Yeah. I actually think some of our other guests that really talked about investing significantly into the product and making sure that the customer experience from the moment that they sign up, to buy it, to they receive it, that that experience is airtight, because that's where you're going to find your influencers, right? I think a couple of the men's shaving companies like Supply and Beard Brand talked about how they built a community of people who move these products. Well, that's the ultimate influence right there, right? Constant good reviews of your products. And if you get lucky enough to find a Dogface 208, then you win. Albert:Dogface is the guy that skateboarded while singing Fleetwood Mac and drinking cranberry juice.Albert:Well, cranberry juice sales, all time high. So, this wasn't a paid campaign or paid activation, sales are at an all time high. They're talking about it might see Wisconsin cranberry farming industry. That's how much in demand cranberry juice is right now. So, if you have a great product, your likelihood of catching a wave I think is much greater than if you're just constantly paying influencers.Stephanie:Yeah. And I like that idea of make sure all your other ducks are in a row first before you start going after influencers. I think we've had a couple of guests who talked about you really need to make sure everything from start to finish, to unboxing, to follow up, that needs to be airtight before you start trying a bunch of other things, because then you are at risk of getting distracted and actually not being able to focus on, not only your core product, but also your customer experience.Albert:You got it.Stephanie:All right. So, the other thing that I think was interesting that a lot of people have talked about is, of course, like omnichannel, and one of our guests is talking about the reinvention of brick and mortar stores, and talking about how it's now turning to be more about experiential experiences instead of just going there to buy something, because so many people now are shifting to a place where they're actually very comfortable buying online, even if they never did before, and going into the store is more about having a good experience and something to draw them in there versus actually making a purchase in store. I think it's all about experiences now and people are going to expect something very different going forward than they ever expected before.Albert:Yeah. I mean, that's the magic question, right? People are trying to... I've read articles about re-envisioning the mall of the future. If I think about current present retailers that are doing a pretty good job, I mean, obviously, Apple Store seems to be like one of the leaders where I had not admittedly walked by an apple store recently, but I do remember back when I did, six months ago, there were a lot of people in there, a lot of people in there touching the products, getting a feel of the products, they made it a very hands-on experience. I can think of other businesses that have done a really good job. Like, why does every Bass Pro Shops have a giant aquarium in the middle of the store? Because they want you to go and look at it. You know what I mean? To pull you in. They know you're a hobbyist. So, I don't know how good businesses are going to be at doing that, but I know that they're all trying. I mean, they have to.Stephanie:Yeah, yeah. I mean, when we had little burgundy shoes on, they were talking about how they were actually partnering with other people, other shops or people that are on the same street as them, even if it was a bank they're partnering with, and they were kind of doing giveaways or doing just different social business events or things like that, to make sure to get people in the store because they're like, "We don't really mind if you buy, but just coming in and getting that customer experience that we have, and being able to get in the vibe of the music, and actually experiencing our brand, even if it's only for a moment, is worth so much more than... Buying online is important, but we also want you to know who we are, and if that means partnering with other brands around us to give you an added benefit..." I mean, that's where I can see a lot of other brands doing that partnership strategy to try and get different customers that you would maybe never touch before in the same place.Albert:Yeah. Really, it remains to be seen that it'll work, because I always think, when I hear about the people with the rain experience, I don't question it at all, but I think also to Borders Books or Barnes and Nobles books, I felt like those are really inviting places. They got nice couches, good coffee, it smelled great, there's always baked goods there, you can read whatever magazine you wanted, or check out books, and they never kicked you out or nothing if you're hanging out there, but it didn't work. There weren't enough people buying the books, they were just chilling, I guess. So, I guess that's the real delicate balance, which is how do you educate, entertain and inform but also do it so much in a way that a person purchases the product versus, I don't know, coming in there and staying all day long?Stephanie:Yeah. That makes me wonder just about the business model, though, of like, are you encouraging people to buy, because... I mean, I don't know how the Amazon bookstores are doing now, but when I went in to them when we were in Seattle, it was just a very different experience because what you could get in the store was not what you can get online, not what you would get at any other bookstore, because there was actually, "Here's a review that we picked out," so you can kind of get a feel for this book, or, "Here's some of our top charting books right in front of you."Stephanie:So, it was kind of like it was bringing an online experience offline as well but in a very different way where I wanted to go in there, I wanted to hang out, but then I also found myself buying online afterwards. I was taking pictures of books and then I was just going on Amazon and buying. So, it seems like they figured it out there, and they don't have too much inventory to where they're holding a bunch of books and expecting them to sell, but it seems like it needs to move more to that model instead of thousands of books hoping someone comes in and buys.Albert:I can see that in a more curated... I know Amazon's experimenting with their five star stores where it's only physical products that have earned an average of four and a half, five stars. So, it's more of a curated experience, which is what we're more used to online, instead of looking at your whole catalog of crap, we see exactly what we're looking at what we want to see or the best stuff right up front.Stephanie:Yeah. And that's also something a lot of guests have mentioned, it's about that personalized experience and making sure that what you're showing the new customers, what they want to see. And I think the idea of curation too. I mean, people are trusting, not only these influencers, but also just people that they trust in general, where it's like, "Oh, my friend likes this." So, making sure that you can kind of show that or have that curated experience I think will be important going forward.Albert:Yeah. So, this is interesting, because I think this is actually a self-fulfilling prophecy of what's happening with consumer behavior and curation, which is, the more curated things become, the more likely or the lower the tolerance a person's patience becomes for browsing. Because I've read stats about how the average web browser, or consumer, whatever, spending less time on pages, clicking through less links, because they're constantly being served, let's say, what they want sooner, faster, so then they react that way. So, it's like feeding itself, right?Stephanie:Feeding the beast.Albert:Yeah. The consumer expectations. Like, if you don't know what I want within two clicks, I'm bouncing.Stephanie:You're done.Albert:I don't got time for those three clicks. I'm out.Stephanie:Yeah. That's tricky. I mean, it is kind of like building up a monster in a way where everyone's going to have to keep leveling up their game with how their new customers or current customers experience their shops.Albert:Yeah, it's going to be painful for merchants to do this, I think, it's going to be very painful. Or they can look at it the other way. There's an opportunity for a technology vendor that can do it. You know what I mean?Stephanie:Oh, yeah. Anyone who's got those good recommendations, yeah, they're already ahead of the game if they're implementing that.Stephanie:All right. So, the next trend, which actually no one really talked about, but it's more around partnerships, but I saw a very interesting partnership. I don't know if you have heard of that show on Netflix called Get Organized. Have you? Where they were going into homes, Reese Witherspoon, and they're organizing her house, and it's very popular now. Maybe your wife watched it. Have you heard of that?Albert:I can conceptualize what it is but I have not seen it or heard of it.Stephanie:Okay. So, they partnered with a Container Store, and they did it in a really good organic way where, of course, they're putting everything in containers and organizing it, and it made the container sales jumped by like 17% after this series went out, and I thought that's a really good example of not just product placement, but doing it in a way that wasn't annoying, and having, not only a partnership from the product perspective, but they also partnered with Netflix in the marketing aspect.Stephanie:So, it's like a good, well-rounded approach, but it also didn't make the content suffer. And I haven't seen a lot of companies do it that well. You always can think of other companies... I mean, there's product placement in almost everything, but you don't walk away being like, "Oh, I really need that to complete my experience." And I can just see a lot of more or a lot more unique partnerships forming like that in the future, where people are thinking outside the box and are not just doing the typical like, "Oh, let's just try this and see how it works." I can see more people experimenting with this, maybe not on that large of a level, but I thought that was a really unique partnership, and especially being able to see the sales jump right afterwards, it shows that it paid off.Albert:Do you think that was because they were actively solving a problem? Right? You're disorganized. I'm going to show you how to get organized. So, inherently the audience that watches it is looking to solve that problem, so inherently they then go purchase those products, or source those products.Stephanie:Yeah. I mean, they definitely, of course, nailed the perfect person who would have an intent to buy as someone who's also trying to get organized, but I think the way they did it just wasn't like hitting you over the head with it, it was kind of like, "Well, here's what we use." It was like, "No big deal, if you want to use it too, this is what we use."Stephanie:And I think that's actually the perfect strategy of like, "We're not going to push this on you, and we're not going to be annoying about it, this isn't an ad, but this is just exactly what we use to make this look perfect." And I think there's a lot of opportunity for other brands to think about that, like, how do you do it in a way where the content is still good? It's not making you feel pressured, but it's in the back of your mind of like, "Oh, this is what I could use to be like Reese Witherspoon," which she's the best.Albert:It's the classic, like, is this a threat or is this an opportunity, right? Because it just depends on the eye of the beholder. But one of the things, to your point, that makes it a threat to existing brands is if they're not good at it. One of the opportunities influencer see is that it's now easier than ever to make and source their own products under their own brand labels, right? Think of the power that Chip and Joanna Gaines have gained, right?Albert:Now it's to the point where it's like they're going to be almost impossible to buy because Magnolia products is coming, and it's already here, and it's going to keep getting bigger and bigger, where they're going to... You already know they know how to organically insert their products into all their content of you already think their style is the best, you already think their builds are the best, you already think their personalities are the best, now they're not even doing the partnership deal, right? Now it's not like, "Oh, go to Target to get the Magnolia collection?" No, go to Magnolia to get the Magnolia collection, right? They're going to cut the distribution network out and just be like, "We're the distributors of this." And that's always a challenge, I think. I do think that's something that the brands get nervous about is because like, if you sponsor somebody and they do a really great job, well, what stops them from cutting you out of the equation?Stephanie:Yep. Which is also what a lot of brands are scared about with Amazon. I mean, we heard mixed messages about that where some people were very excited about partnering with them, they were getting championed on that platform, Amazon was promoting them, and they weren't really worried too much about it, they're like, "Why wouldn't you be on Amazon, because that's where everyone said you should be selling on there?" And then we heard quite a few other ecommerce leaders who were like, "No way would I get on there. You're not going to make as much money. You can't control the experience. You can't control where it's being seen. And I want to make sure my DTC company is being portrayed how I want it and I don't want it to be knocked off on Amazon." So, the same kind of thing there.Albert:Yeah, that's it, and that's never going to stop. Constant threat market share takeover.Stephanie:Oh, I know. Constant battle, but interesting to watch. I think those people should be on Amazon, though, because I do think that is where so many people are. It seems like, yeah, it's where you need to be.Albert:Yeah. Here's what's interesting. The biggest players have kind of stepped off, but like Nike, Nike has got so much... Nike has enough power, I think, to step off that platform, but if you're trying to be discovered, I mean, it just does seem overwhelmingly hard to do it without that distribution network. I think it's just tough.Stephanie:Yeah. When we were talking about ShoppableTV, I'm also thinking about... I mean, you might know this better since your kids are on some of these gaming type of platforms, but having Shoppable worlds, whatever that may be, seems like something that could be coming in the future but we're not there yet, probably. I mean, I know we are when it comes to virtually shopping for things, that like, "Oh, I want to make sure to get this. Whatever this is in this world, I want to buy it," but it seems like there could be an opportunity as well for implementing your products into those worlds that are being built up right now.Albert:Yeah. Personally, I'm not as bullish on that because I still think people want to... I don't know. I don't really know, maybe because I just don't do it myself, because I definitely see my kids being drawn in when they're playing games, like they recognize products. What's weird is, when kids. To me, it's what's weird. So, for anyone who has kids that play Roblox, my kids see things on Roblox and they want to buy them, and they're digital products.Stephanie:Yeah. What are they? What are they buying?Albert:Like the new sword? They're like, "I want this sword." It's like, "What sword?" It's like, "The digital sword." It's like, "What do you mean digital sword." It's like, "My character can carry this sword if I buy this with real cash." And that makes no sense to me. What are you talking about?Stephanie:Exactly. I think it could be transitioning eventually. I mean, yes, people will always want those digital swords, I heard that people are buying t-shirts in there. I want to make sure my little avatar guy is wearing the coolest t-shirt. I don't really understand that, but then I don't know if you heard about Fortnight had Travis Scott do a virtual concert and was watched by millions of people.Albert:Yep.Stephanie:There's a very big reason why people would be like, "Whatever he was wearing, I want to wear."Albert:Now, did you hear about Travis Scott's McDonald's deal?Stephanie:No. What's that?Albert:It was like the number one selling meal for the last couple months.Stephanie:Just McDonald's in in general or what's his meal?Albert:The Travis Scott meal. I don't know. It's literally his meal. You know what I mean? You can have a number one, you can have a number two, you can have a Travis Scott.Stephanie:It says the Travis Scott meal is a quarter pounder with cheese, lettuce, and bacon.Albert:I'm just saying that's the power of you talking about a digital world. Yeah. There's the power of influence too, but he's already a mega celebrity, right? But I view it as this, it's like, what people are into, and this is why, like I was saying before, I feel like I age out of this stuff very quickly, and we're talking about ever evolving change. I came from a time where if I didn't have a physical product in my hand, I didn't think was real. I remember when mp3s first came out, I was like, "Why would I buy an mp3?" It's like, "It's a digital version of your songs." "What if I lose it?" They would be like, "What if you use your CDs?" "But at least I'm in control of my CD." You know what I mean? Like, that's my CD. I know where it is. I take responsibility for it. I was slow to convert there.Albert:And I feel for me, I'm always slow to convert to digital products, but when I watch my kids, it's just unbelievable. I don't even think they're interested in physical products. They keep wanting digital things. They want more games, they want more currency for their players, they just want this stuff. So, that's why I kind of didn't answer that because I was thinking simultaneously in my head, this is never going to work, but I think I mean this is not going to work on me but this is going to work on my kids, because it's happening right now. I get things all the time on my Google Play app, iTunes account, like, "What is this?"Stephanie:Why don't you buy one more virtual sword?Albert:So, will company start integrating like t-shirt... All right. So, let's take one of our t-shirt clients, right? We've kind of asked our guests on Up Next in Commerce, we've asked this to all of them. How do you convey that your product is soft, silky, whatever their product descriptors are, to someone without them touching it? And so it makes you wonder, in the future, is someone going to see a yellow hammock in their virtual world and be like, "Huh," and it'll pop up a ding like, bing. "Not only can your character have a yellow hammock, you can have one too." It's like, "Oh, okay, cool."Stephanie:Yeah. Especially if you can kind of see it blowing in the wind, or you can see that shirt like, oh, that's form fitting on this person in my virtual world that I really like. If you can kind of see things and details about it that mimic it. I mean, it seems like there's an opportunity there, it might not be here just yet, and you definitely have to figure out the demographics behind it, because, yeah, I mean, like you said, you might not be interested in that.Stephanie:However, I was listening to a pretty good interview with this guy, Matthew Ball, he was the former head of strategy at Amazon Studios, and he had a really good episode talking about how he was the same as you like, "Oh, this just isn't my world, however, I see actually a lot of companies, they will start being able to adapt these same types of technologies to where the older generation will actually start adopting as well, they just are trying to figure that out right now like, what will they feel comfortable with and what are they looking for? Like, what problems can you solve to get them there?"Albert:It's going to be pretty fascinating when someone's upsell customer journey path is actually get the digital avatar to consume this product first and then offer the physical. You know what I mean? When we talk about the hammock, can you imagine that, like, "Oh, my avatar really likes this hammock. He seems great. I think I might get one for myself in real life." What?Stephanie:I mean, I kind of would. I would do it. You need to get in these worlds to really experience it, but I mean, it does just seem like that is where the world is trending right now, around these games. I mean, a company I follow really closely is Epic Games, I think they're-Albert:They're in out neighborhood. [crosstalk 00:35:26].Stephanie:I think their leadership team is brilliant around what they're doing with their platform and how they're essentially giving away almost all the underlying technology that other companies have been charging for for a really long time, and they're kind of building this really big moat to be able to expand in a bunch of different ways. So, I kind of keep tabs on them, and that also, of course, influences my commerce hat when I'm thinking about too like, "Oh, wow, these two worlds could blend together in a really unique way and whoever gets there first..." Usually, the first movers are the ones that can get that arbitrage. So, seems like an interesting spot to watch.Albert:Yes, the Unreal Engine, for our listeners that are not familiar. Epic built a platform called the Unreal Engine of which you can build your gaming world on so that you could use... think of it as less code, you had less code, less character development, it's all built for you, you just add your characters and they can build worlds for you. How they do it is they charge you a royalty fee, I believe it's like 5%, but only if your sales are over a specific number.Stephanie:Yeah, it's very beneficial to creators, and that's why a lot of people are moving to that platform now because they're used to having these apps where certain stores, they're taking like 30 and 40%, and if you move to Unreal, you're essentially keeping the majority of your sales.Albert:Yeah, and you don't have to pay until you reach a certain number. So, by the time you're paying Epic, you've already made it, and then you're fine with it, I guess. The number is tolerable. By the way, if you follow Epic Games founder, Tim Sweeney, on Twitter right now, he's in a constant fight with Apple over [crosstalk 00:36:56].Stephanie:Oh, I know.Albert:He does not like it.Stephanie:I wouldn't either.Albert:It's a fun follow, though. It's a great follow.Stephanie:Go, Tim. I'm going to follow you right now.Stephanie:All right. So, the last one that I want to talk about is... I think this is interesting. You might be like, "That's weird." But I think there's such a big opportunity for optimizing, not only your website for voice searches, but also potentially building out custom Alexa skills to solve a problem. I see people doing that right now, but not really in ecommerce as much, but think about having an Alexa where you're like, "Hey, Alexa, tell me what wine goes best with this kind of recipe." Or, "Hey, Alexa, suggest some outfit for me based on the weather today." And you kind of build a tool that's actually helpful that's also you know, of course, very close to your brand. And so you can become top of mind by building out those skills or just implementing voice search in general. I just think the world is headed in that way because the technology is starting to get better, but I don't see a lot of brands jumping on that right now.Albert:I think the ability for AI to understand intent and meaning isn't quite there yet. I'm trying to think of myself using my own consumer behavior, right? Do I use voice to text right now to enter searches? Yeah, because it's a lot easier than typing it in or swiping it in, right? So, if I want to ask Google a question, I will just click the mic button and talk. Would I do that to solve problems? I don't know, but I think I haven't yet because contextually, it's very difficult, but it won't be far, right. So, right now, I think a lot of people Google best. Do you know what I mean? Like you said, best way to do X for Y, right? And then the next level is going to be can NLP technology, AI technology, whatever it is going to be that understands the nuance and intent and meaning start making it super personalized recommendations?Albert:So, can you imagine if you went to Home Depot, because what you're talking about would be super cool, if you go to Home Depot and say, "Hey, my garbage disposal broke. How do I replace it?" And it just comes up with like, boom, "You're going to need this, this, this, this," and then it gives me a how-to guide of how I buy a garbage disposal, I'm going to need these tools, I'm gonna need the sealants, and getting them-Stephanie:Can you imagine saying that, like, "Here's exactly how you're going to fix it. Let me send you a video to your phone." And like, "You need like Albert's brand of screws." Like, they're literally dropping your own products in there like, "This is how I would fix it, and also, here's a how-to video," and you walk away being like, "Wow, I not only bought that brand stuff, maybe, or I didn't, but they're top of mind now. They actually helped me fix my garbage disposal." How cool would that be?Albert:So, speaking of this, there was a while ago where I believe it was the president of O'Reilly, I'm pretty sure it was. The O'Reilly Auto Parts basically came out and said that Amazon was not a threat because buying car parts is very complicated. I'm not saying he's wrong, right? Right now car parts really aren't bought on Amazon because you have to know what model you have, you have to know the year, the make, the model, you actually have to know something about fixing cars to even begin to find the part. But can you imagine a future where you can ask it a question like, you go to O'Reilly or wherever you go and you say, "My air conditioner is not cold," and it remembers your car models, "Oh, you're going to need X, Y, Z. Would you like me to book you an appointment if you can't do this yourself?" Like, "Yeah, book me one. I don't want to do this?"Stephanie:Yes, please. Yeah. No, I mean, that's where I think the world is headed. And I mean, we did have a good interview, it wasn't our first 50, it was one of our more recent ones, talking about the world of identity and how you should be able to go places and you shouldn't always have to refill in your info, it should know maybe what's your brand of car if you put it somewhere else before. I'm trying to think of what episode that was.Albert:Fast.Stephanie:Oh, yeah, Fast. Yeah, that was such an interesting episode. I mean, now it's coming up right after this one drops, but [inaudible 00:41:10], so interesting where he was going through. Not only are they doing payments and identity, but where the world was headed around you should always have a Buy Now button on every single one of your products and that you shouldn't just make people add stuff to cart and then do the shipping and all that, you should let them buy when they want to buy it. And he was talking about the conversions behind that. But all that gets back to the identity piece, which is what you're talking about, going into an auto part store, you should be able to say, "Here's what I'm looking for," and it should know, "Okay, based on the information I have about you, here's what I'm going to recommend for you," and make it seamless and frictionless.Albert:Yeah, everyone wants that.Stephanie:My future. I don't know what yours is, Albert?Albert:Well, I think it's going to get there. It's not a matter of if, but when, but I still know that NLP... for anyone that's used an AI chat bot yet and been frustrated because you asked a simple question and it's like, "I don't know what you're saying," it's like we're not there yet, but I think it's coming, for sure it's coming. The technology providers, though, are going to be the ones focusing on that the most. I don't know when the merchants can start tapping into that resource.Stephanie:Yeah. That's why it's interesting to kind of keep an eye on these new startups and new tech companies that are launching around this stuff, like Fast, or even like the technologies like GPT-3. When that came out, I was just reading a whole article about how this guy created a program where you essentially can just talk and it'll build a website for you. So, you can say, "Create a red button, have the drop down say this, have the picture do this, grab the picture from here." And it is no code. You are speaking and it is coding for you in the background.Stephanie:I think the world is headed there but you just have to try and stay on top of those trends or the companies and try things out, honestly, experiment with it and see if it could work without bogging things down. I know you have been the first to say that the amount of plugins that you add on your website are just going to bog it down, and website speed is number one, so there is that balance, but I think it's interesting to stay on top of the trends outside of just your current industry.Albert:Yeah. Are we going to get to the part where we all have our own Jarvis? I don't know. But if that happens, it will be cool. Jarvis from Iron Man, for anyone that's not familiar with what I'm talking about, right?Stephanie:I was actually familiar with that one.Albert:Yeah? There you go. Look at you watching movies and stuff.Stephanie:I know. Look at me. I'm so trendy.Albert:It's not trendy. It's definitely very old. I think it's like a decade old now.Stephanie:Yeah. Still great, though.Albert:Yeah.Stephanie:All right. Are there any other forward looking trends that you think are interesting right now. So, we essentially covered the things that were in the 50 episodes, which were awesome and really cool, high level themes, but all the episodes had really good, juicy nuggets in each one. And then we looked at some of the forward thinking themes that maybe weren't covered, but I just think are interesting. But anything else you can think of where you're like, "I think a lot of people aren't thinking about this or aren't paying enough attention to this world that could help an ecommerce store owner"?Albert:Well, we got to do a big shout out to my awesome producer, Hillary, who loves Peloton.Stephanie:She does.Albert:Because Peloton is a very fascinating-Stephanie:[crosstalk 00:44:23].Albert:So, I bought stock in Peloton, and here's the reason why. I've never encountered a brand that I can think of where people so emphatically talk about it. Peloton and maybe CrossFit. Everyone says, "The first rule of CrossFit is you can't stop talking about CrossFit," I think that's also applicable to Peloton, because people who have Peloton love Peloton. So, I think this concept of building community so that your product extends beyond the purchase of the product, meaning like you buy a physical bike but you would stay subscribed to Peloton services. Because I think every brand, or not every brand, because could you do it with a ball? I don't know.Albert:But brands and products companies are probably trying to figure out how do I create a subscription community? I think that is going to be a trend that you can capitalize on now because it doesn't require, I don't think, as much technology that doesn't exist, but it's more like how do you build ongoing services at a price point where customers never want to leave you? So, like, I don't know. Let's use my example of kitchenware. Should fork, and knife, and bowl companies have active cooking communities? I think they should.Stephanie:Yeah. I mean, that was our interview with Food52, Amanda Hesser, that's exactly what they did. They built up this huge online community first and then they started reselling other people's products, drop shipping them, and then they created their own brand, and they did it in a way where they're like, "By then we had this huge community that we were doing cooking things together."Albert:Yeah. They could already forecast their sales. They were like, "Oh, we can automatically assume how many people are going to buy this."Stephanie:I know. And that was a long haul for them. I mean, she was the first to say that, however, I'm like, you essentially are launching to an audience that trust you, trust your content, you have this love for just anything that you're doing after you build this community, but trying to figure out how to do that right or figuring out what actually keeps people coming back and how to keep them engaged I think is really difficult without being annoying and without pushing your product too much. When you start in a more content focused way, it seems like it can be a lot more organic to build up those followers to then shift into a product where you have that trust. But it does seem hard when you're launching a new like DTC company and also trying to do content at the same time, it seems hard to figure that piece out.Albert:Yeah. And if we go back in time, right, Michelin figured this out. Michelin figured out that people weren't driving enough, so they created their star review system because they wanted people to drive and experience things all over the world, to the point now where here we are today, people still talk about Michelin star ratings for restaurants. It's still that important. People can't put two together and say, "Why would a tire company create that?"Albert:So, if you have that today, I think that's probably the next biggest trend, and you can already kind of see it happening. I think more products are going to try to create worlds or problems that their products and services solve, or whether it's exploratory or problem solving, I don't know. But when it comes to Peloton, I just think about the community that they've built, the fact that people just rave about the product. We got our buddy Hillary here, she's got a bike, it's not broken. She says, "They launched a new bike. The screen tilts so I can do yoga and then get back on the bike." It had a price point, a really high price point. I mean, Hillary was considering getting a loan to get this thing, which, by the way, they offer, they offer financing.Stephanie:We're going to put Hillary's... her like affiliate code, I don't know if she one. She needs one.Albert:Well, I'm telling you, the brand love that she has... But it's not just her. I say Hillary because, Hillary, we obviously work with her, but people love this product.Stephanie:There you go. Are you looking at our prep doc? She says h_tag24. Peloton all the time.Albert:Okay. If you want to buy, h_tag24. If you want to follow our buddy Hillary on Peloton, not only will she kick your ass in all these calories, or I don't even know what you guys measure.Albert:However you score points, she's scoring all the points.Stephanie:I don't know if that's a thing.Albert:Outputs. I don't know.Stephanie:Okay, outputs got it. This has gone into a bad hole. I'm not sure what we're talking about here.Albert:Well, we were saying like, what's the next thing to be aware of? I mean, I think that is closer than all those voice searches and things like that that you talked about, which I think are coming, I think you're going to see more companies build communities, and I also think you're going to see more companies burning out customers by trying to make everything like SaaS. Because one of my favorite Twitter handle to follow, everyone check it out, it's called the Internet of Shit, it's just non stop products that don't work if you aren't subscribed to their services. So, businesses out there that try to make me subscribe to make my refrigerator work, I'm anti-you. All right? Definitely anti-you, don't want to hear about it. So, follow the Internet of Shit, if you guys are curious.Stephanie:I have follow that one.Albert:But that's the delicate balance, right? How do you build a community of value that you charge for versus, I don't know, putting someone in entrapment where you're forcing funds out of them every month just to use your product?Stephanie:Yeah. I especially think after everything with COVID, people are also going to be dying for that community, even if it has to be online, I think it's going to be bigger now than it ever was before, because people have been cooped up and haven't been able to have that community like they may have been used to or they're actually maybe cherishing it in a different way now and they're trying to look for that. So, I think it'll be a big opportunity.Albert:There you go.Stephanie:All right. Anything else on your mind? If not, I think this was a fun episode. It was a good one.Albert:I hope so. I can never tell.Stephanie:You're really not, yeah. You're almost like, "I'm not sure." But yeah, I think this episode was awesome, it's really fun just kind of reminiscing through all the episodes we did. I can't believe we've already had 50. If you have not given us a review and a rating and subscribed, please do, because that helps spread the word, and we would love to hear how we're doing. We also have some really good interviews coming up, like we were mentioning earlier, the CEO Fast is coming on, we have a really cool company, Handwrytten coming on with [inaudible 00:51:04], Sheets and Giggles, Ring. We've got some big names coming up here, and yeah, I'm excited to do this next recap after the next 50.Albert:Until then.Stephanie:Right. Thanks, Albert.

https://www.patreon.com/Adrunkennightout https://www.facebook.com/ADRUNKENNIGHTOUT https://www.instagram.com/kenhamlett/ bigblackshlongs.com https://www.facebook.com/stephanie.gilmoreflynn This episode we talk grown up lady friends, getting drunk and running an illegal fight club

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

Dr. Sheila Gephart. Photo courtesy of Dr. Sheila Gephart. Episode 8 features Dr. Sheila Gephart, neonatal nurse scientist and assistant professor at the University of Arizona College of Nursing. During this episode, Dr. Gephart provides a comprehensive overview of GutCheckNEC, a first-of-its-kind, 10-item risk assessment that she developed for the early detection of NEC in premature infants. She discusses: * Her transition from bedside nurse in the neonatal intensive care unit to her development of GutCheckNEC—what she calls a “real-time, early warning score for NEC,”* The 10 risk factors that make up GutCheckNEC, their associated symptoms, and how risk is communicated,* The development of NEC Zero, an intervention that has evolved out of the Unit NEC rate component of GutCheckNEC,* The strength of evidence for the use of probiotics in the prevention of NEC, and* The importance of shared decision making in the NICU. Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. This episode was produced in part by the TeacherCast Educational Broadcasting Network. [powerpress] STEPHANIE VAUGHAN, HOST: Welcome to Episode 8 of Speaking of NEC—a free, audio podcast series about Necrotizing Enterocolitis. Produced by The Morgan Leary Vaughan Fund, and funded by The Petit Family Foundation, Speaking of NEC is a series of one-on-one conversations with relevant NEC experts—neonatologists, clinicians and researchers—that highlights current prevention, diagnosis, and treatment strategies for NEC, and the search for a cure. For more information about this podcast series or The Morgan Leary Vaughan Fund, visit our website at morgansfund.org. Hello, my name is Stephanie Vaughan. Welcome to the show. I’m the Co-founder and President of The Morgan Leary Vaughan Fund. Today, my guest will be Dr. Sheila Gephart, neonatal nurse scientist and assistant professor at the University of Arizona College of Nursing, who developed a first-of-its-kind, 10-item risk assessment for the early detection of NEC in premature infants called GutCheckNEC. During our conversation, she will discuss in varying degrees: Her transition from bedside nurse in the neonatal intensive care unit to her development of GutCheckNEC—what she calls a “real-time, early warning score for NEC,” The 10 risk factors that make up the acronym GutCheck and their associated symptoms How risk is communicated, The significance of the Unit NEC rate component in GutCheckNEC, and how that led her to develop the NEC Zero Intervention, The strength of evidence for the use of probiotics in the prevention of NEC, and The importance of shared decision making in the NICU. With that in mind, let me introduce my guest today. Hi, welcome to the show. This is my guest, Dr. Sheila Gephart. She is a neonatal nurse scientist from the University of Arizona College of Nursing. Hi, Sheila, how are you? DR. SHEILA GEPHART, GUEST: Good, thank you, Stephanie! STEPHANIE: Thank you! So, we have had more than one person mention you on our show in previous episodes, so I’m thrilled to have you join me today and would love to let you talk a little bit about your background and how you got involved with Necrotizing Enterocolitis. DR. GEPHART: Well, I am very thankful to be asked to be on the broadcast today, and I will tell you that I started my interest in Necrotizing Enterocolitis risk understanding when I was a bedside nurse. I have been a nurse since 1997, and I worked in the neonatal intensive care unit as a bedside nurse taking care of babies, and many of them were really convalescing. They were doing well, but then we had a subset of babies, or a clump of babies, that all developed this horrible disease within about three weeks. And now I know the clustering of NEC is very common, or not common, but it does happen. STEPHANIE: Right. DR. GEPHART: But then I didn’t really understand a whole lot about the disease, but I was very concerned because I realized that we had been concerned about these babies, as nurses, for hours to days before the actual diagnosis of NEC was made. So what happened at that point was I had the role of getting into the data for our NICU. I collected the data and reported the data for a large registry called the Vermont Oxford Network. And so I was focused on looking at the baby’s case and looking at the research and looking at the data, and I realized that there was a constellation of risk factors that kind of coalesced for these kids, that all of these things seemed to snowball with these babies who developed NEC, and we really had no context for talking to physicians to communicate why we were concerned. We were using terms like something’s not right with this baby, and from there, it really launched me into the next five years of understanding more about NEC risk. STEPHANIE: Okay. And can you talk to me a little bit about the protocol – I think it’s a protocol -- that you’ve developed called GutCheckNEC and how you got from starting to look at the data to compiling and understanding this set of risk factors? DR. GEPHART: Sure, I’m happy to talk about GutCheckNEC. So, being a bedside nurse, sometimes I would work in the middle of the night, and I needed a strategy for putting things together so I could remember them. And when I thought about NEC, I thought about well, we just need to check the gut. So GutCheck was kind of how it organized these risk factors, and I wrote GutCheck in a line straight down, and I remember one day I was at a delivery, and it was about three in the morning and it was taking a while for the baby to be born. And I was trying to understand all of the research that I had been reading about NEC risk and so what I did was I write GutCheck straight down on a napkin and horizontally for each letter I wrote the risk factor that was associated with that letter, and so that helped me organize what I was reading in the literature. But really it started out as just wanting to develop a risk assessment so nurses could really know what the risk factors were, physicians could know what the risk factors were, but then also put the symptoms in the context of what was going on with the baby. So that’s where I started, but then I went into a Ph.D. program, and in science you have to be very systematic. And so my literature review was the systematic beginning. But then what I did was I asked neonatal NEC experts how relevant they thought the different risk factors were to actually developing NEC. So I asked them to rate the relevance, and we went through three rounds of surveys to determine if we had the right list of risk factors, so that was very useful. We got rid of some, we kept most of them and added a few. And then, the next step was I got a very large dataset from a group of neonatal practices here in the US called The Pediatrics Medical Group, and I built, this is research speak, but I will tell you that I threw all of the risk factors into a statistical model to see what fell out as the most important, and the way statistical models work is that they keep the most important things that account for most of the explanation for what you’re looking at, and they get rid of everything that’s not quite so important. STEPHANIE: Okay. DR. GEPHART: So we went from like 33 risk factors down to essentially ten risk factors for GutCheckNEC. And then we tested it to see if it actually discriminated or told the difference between the kids that got NEC and the ones who didn’t, and it showed pretty good discrimination, or separation of groups, for the kids who had the most severe NEC compared to those who didn’t get NEC at all. STEPHANIE: Okay. DR. GEPHART: So that was the work we did, and now we’re taking this ten item tool and we’re trying to combine it with clinical science so that we can really have a real time early warning score for NEC. STEPHANIE: Great. Can you sort of go down the list just for parents that might be listening or family members if they’re seeing any of these risk factors? DR. GEPHART: Sure, I’d be happy to do that. The items that we kept in GutCheckNEC, like I said, there are two versions. There’s the one before the statistical modeling and then there is the one after, and the one that’s before is actually more comprehensive. And if you think about just writing GutCheck down linearly, you think for G, you’ve got growth restricted, so they’re born really small for gestational age, you’ve got gestational age. Those are the main ones that I always thought of with the G. And then with U, the one item that the experts recommended adding was the unit NEC rate, because infants who are in units with high NEC rates are more likely to get NEC, and so I didn’t understand that finding. I’ll talk about that in a minute, about the unit NEC rate. T, if you talk about T, transfusion. There is an association that we see in lots of studies with transfusion and NEC. We don’t see any evidence of causation, but the studies aren’t designed to show us that, so there is a temporal relationship or a time based relationship between transfusion and the most severe NEC. That said, there is a lot of babies who get transfusions and don’t get NEC. So that’s what makes it hard. STEPHANIE: Right. DR. GEPHART: What else goes with T? I’m going to stick to the final version, okay, as we think through the acronym. And then for C, signs of infection, so chorioamnionitis is when mom has a really bad uterine infection prior to the baby being born. Some preterm moms have this because—we don’t know exactly why they have this, but chorioamnionitis, particularly if it’s invasive, if it’s really severe, that is a risk factor. Also cardiac kids are going to be more at risk, so if you think of the C, kids who have had heart disease or heart malformations, particularly those that are low oxygenation kinds of defects… STEPHANIE: Right. DR. GEPHART: ..and there are some more for C but I don’t recall exactly what those were right now, but I’m just going to stick—oh, culture proven infection. That also goes with C. So if babies have had sepsis, particularly more than once, which sometimes these really early babies do get multiple bouts of infection, that is a risk factor. So that stayed in my model long term. Enteral feeding is definitely a risk factor that all babies are hopefully exposed to because we want them to be fed. That I understand a lot more now about the details of enteral feeding, and that particularly if the enteral feeding is formula, that is very important. We know formula is a high risk factor. There is a whole slew of argument about cow’s milk based fortifiers that go with that as well, so there is some argument about how extensive of a risk factor that is, but formula and enteral feedings certainly. And then the H, I skipped the H. That would be hypotension treated with medicines to bring that blood pressure up. So hypotension is low blood pressure. A lot of preemies have episodes of low blood pressure, but we know that the most sick are going to be hemodynamically unstable which means that their ability to regulate their blood pressure and keep their heart rate within a good level is not quite as solid as a kid who doesn’t have those light fluctuations, so that was a risk factor that did stay. Also race. Race stayed. The experts did not think that race was a risk factor, and they were pretty, if you remember the stages that we used to develop GutCheckNEC, we asked experts about how relevant they thought these risk factors were and they really didn’t think race was relevant. But it was so strong in the model, I couldn’t get rid of it. So if a baby is either black or Hispanic, that puts them at higher risk. Now, the reason for that we think, we don’t really know exactly why that stayed in the model, however, we know that black babies are very much less likely to get human milk… STEPHANIE: Okay. DR. GEPHART: ..than white babies, and that is something we can fix. So that’s really important. As I went through these risk factors that are in GutCheckNEC, I started to separate in my mind what’s modifiable, which is what of these can we do something about and what is non-modifiable? And what I saw really was quite a few of these things were modifiable that stayed in GutCheckNEC. You can do a query online for GutCheckNEC and it will pop up the actual, you’ll be able to find GutCheckNEC in the literature. It’s published so anybody can find it. But the thing that was so interesting to me, and I’m probably going to go off a little bit here, is that the NICU NEC rate consumed a huge amount of the variants in this tool which means that if we were to say that these items explained an infant’s risk for NEC. The NICU NEC rate explains three times as much as gestational age, three times as much as transfusion. So it was so important, and what we saw in the sample, we had 284 NICUs in the sample that we used to build GutCheckNEC and to verify it, of those 284 NICUs, we saw huge variance in NEC rates. So that was pretty concerning, and it wasn’t something that I went into the research expecting or looking for really even because I had read 70 papers about NEC risk, and invariably, they would start with Necrotizing Enterocolitis is a disease that we have very few answers for. We don’t really know why it occurs, but we know that premature babies are at risk and that is the most consistent risk factor across studies. So prematurity. STEPHANIE: Right. DR. GEPHART: Everybody blamed it on prematurity and low birth rate, and very few said anything about—oh, and we know, actually we have about six large studies from 20 years ago that show that unit NEC rate is consistently an issue. So that is something that I didn’t expect to find, but I found, and then I was able to go back into the literature and find other studies that verified it. STEPHANIE: Excellent. That’s a phenomenal amount of information, and I think that’s really great for parents going into the NICU to have in their minds. DR. GEPHART: And I think, I apologize to the parents for throwing out all these terms, but I know that you’re smart, and you can handle it. Okay, I’m just going to give you credit, because if you’re NICU parents, you’re super savvy, and you know how to find information. STEPHANIE: Right. DR. GEPHART: But one of the things we were really concerned about with NEC is how we communicate risk to parents and how parents are really the eyes and ears of understanding what’s going on with that baby just like the nurses are. STEPHANIE: Right. DR. GEPHART: And they are really better situated, honestly, to be able to identify the trends in their own kid, because that’s all they’re worried about. STEPHANIE: Right. DR. GEPHART: They’re not worried about the delivery down the hallway or all these other things, they are the expert. So one thing I’ve been working on trying to frame this message for parents as partners on the team looking for signs of any kind of complication and I think if they know to speak up. To keep track and to speak up if things don’t seem right, and I’ve heard many physicians actually say that it’s the parents indication of concern that will make them stop, and think slower, about what’s going on with that baby. So either the nurses concern or the parents concern, because often the physician, as excellent as they are, may not be right at that bedside… STEPHANIE: Right. DR. GEPHART: ..at that moment when something is changing. STEPHANIE: Right. Right And we did have an experience between Morgan’s surgeries where there was a concern in the NICU, and I can’t even remember who had mentioned it at rounds of attempting to give him—I don’t know if it was formula or breast milk—but giving him something that the surgeon had previously not agreed to—and it was a whole day of me trying to get in contact with the surgeon and making sure that nobody did anything until the surgeon had said yes or no. And he called me back from outside of the surgical room and said if anything like this happens, call me, I will call you back. So we definitely found that the doctors are very receptive, and especially when you raise an alarm, and to give people concrete things to look at for their babies I think is a wonderful tool. So thank you for sharing this. DR. GEPHART: Absolutely! And I can say that within the next few weeks, probably by the time this podcast is released, our website will be active, and on that website are parent materials that we’ve created that are designed to help them. Anyone can download these parent materials, they can use them in their NICU, and they are basically pamphlets to talk about things to watch for, what you can do to prevent NEC, and what the signs are, and a little bit about what happens afterwards. Because you know the first-hand experience of how different your life is… STEPHANIE: Right. DR. GEPHART: ..coordinating care for a child who’s had NEC. STEPHANIE: Right. DR. GEPHART: So the long term impacts of dealing with life after NEC, I know Laura Martin was on the broadcast… STEPHANIE: Yes. DR. GEPHART: ..recently… STEPHANIE: Yes. DR. GEPHART: ..and her story has been such an important part of my development as a nurse scientist. Think beyond just the NICU stay, to think about how NEC impacts these kids forever. STEPHANIE: Right, right, and we’ve been very lucky that Morgan has had (knock on wood) minimal residual effects. We see a little bit, but I mean, I looked at Laura’s story and they are doing a phenomenal job with him. He is a miracle. DR. GEPHART: Yeah, Joseph is pretty awesome. I haven’t had the chance to meet him in person yet, but Laura and I collaborated to write up his story, and that paper is going to be coming out in the next couple weeks in Journal of Perinatal and Neonatal Nursing, and it is a testament to his resilience. STEPHANIE: Right. Hers too and her husband’s and the family’s. DR. GEPHART: It’s pretty awesome. STEPHANIE: Definitely send me those links and we can certainly share that with everyone—direct links in the show episode notes. So I’ll ask you, now that GutCheckNEC is I’ll say standardized if that’s a correct term, is there anything that you’re looking towards in your research moving forward from GutCheckNEC? DR. GEPHART: Well, that’s a great question, and GutCheckNEC is a risk assessment, it’s a tool. It fits on one page. We’ve just gone through a process where we’ve added to it a structured communication protocol, so if a NICU wanted to use GutCheckNEC, we would have them complete a request form, and on one side is GutCheckNEC, and on the other side is the structured communication form, which also clues the nurses, the parents for which signs and symptoms to look for and how to communicate it. So that’s easy. So that’s where GutCheckNEC is going. We’re also trying to combine it with clinical science right now, so that’s the analysis I’m working on right now, and I’ve worked with a great collaborator, Sherry Fleiner from the Inner Health to do that work. But beyond that, one of the things with research, you do a project and then you have these findings and then there is something that just kind of nabs at you and it doesn’t fit like you expected it to. And for us, that was the unit NEC rate component of GutCheckNEC that carried so much weight in the score, and it demonstrated across the 284 NICUs how variable NEC rates can be. So what we did next is we asked the question, well, why are they different? Why are the NEC rates different? And what if we did something to try to standardize prevention care? So there are a couple of main things that prevent NEC. One is human milk—very, very important starting with colostrum for oral care. The other thing is standardized feeding protocols, stewarding antibiotics, and I can kind of get into more detail there, and then there is a lot of controversy about transfusions. STEPHANIE: Right. DR. GEPHART: So those components, those four things plus a strategy for early recognition, we’ve put those components into an intervention we call NEC Zero, and the name of it is designed to convey that we’re hoping to get NEC to zero rate. Now, this is an audacious goal. But why set goals if they’re not crazy? This is an audacious goal, but it was not my idea. There was an editor for Journal of Perinatology, his name is Jonathan Swanson, and he wrote a paper the year that I finished my dissertation, so I think that was in 2012, it might have been 2013, and the title of that paper was “Can We Get NEC to Zero”? And if you ask scientists this and clinicians this, you will hear a lot of concern that this is an audacious goal. Like of course, we’re not going to get NEC to zero, we don’t even know what causes it. However, we do know some things that consistently reduce the risk for NEC. So human milk is, like I said, those five components, but human milk is so primary. So now we’re trying to put those interventions together, make them implementable so that people in the NICU in Delaware could implement them with the same consistency and clarity that people in Texas could do. STEPHANIE: Right. DR. GEPHART: So that bundle of practices is NEC Zero. So the process for NEC Zero right now where we’re at in the project is that we’ve gone through kind of an expert process of refining the recommendations. So we’ve gone through that, we need to publish that, but we’ve got them. We had a really great expert group of almost 20 people, and four of those people were parents. Laura Martin was on that group. So we’ve got the recommendations, now we’re trying to break those recommendations into implementable steps, and we’re creating tool kit products to go with the NEC Zero intervention. So pieces of that are— GutCheckNEC is definitely a primary component of that. Frankly, GutCheckNEC has the least strong evidence of any of the components in the tool kit. But it’s something that is actionable, it’s something that we can use to monitor, and we know that monitoring and evaluation is a key component of implementation success for anything. So that’s where we’re at right now is we’re working on NEC Zero. STEPHANIE: Great, that sounds excellent. Do you have a projection of when people might see this? You said you’re looking to get it published, or the first stages of it getting published? DR. GEPHART: Right. We’re working on refining the recommendations really in terms of publishing any sort of a recommendation list or a guideline. They carry much more weight if you have the authority of a professional organization behind them. So our strategy right now is to try to link up with some professional organizations and see if we can get some endorsements for them. So if any of your listeners are prominent members of the American Academy of Pediatrics, the National Association of Neonatal Nursing, The Academy for Breastfeeding Medicine—any of those groups would be excellent proponents. So we have the recommendations, we have some parent products that will be available, like I said, within a few weeks once our website gets done, and the other pieces of it being available, I will say that we’re testing it right now. So with the testing, there are two things we’re doing. We have the recommendations, we’re asking experts to kind of assign relative importance to the different parts of the intervention, and that score, we’re creating a ten point score for the NEC Zero adherence score, and that’s almost done. And then we’re going to look at relationships between adoption of NEC Zero practices and NEC rates, because we really don’t have a great evidence body for understanding why NEC rates differ so much NICU to NICU. STEPHANIE: Right. DR. GEPHART: So this is kind of an effort to add to that body of evidence of understanding why are they different. We don’t know what we’ll find, that’s the beauty of research is you start with a hypothesis, you get your data, you test your hypothesis, and you see how it turns out. STEPHANIE: Excellent. This is great work, Sheila. I mean, it sounds like it’s really sort of simple, but I’m sure it’s not. DR. GEPHART: That’s right! It does kind of sound simple, doesn’t it? STEPHANIE: Or that it maybe should be simple. Hopefully it will be simple, but it sounds like parents in the NICU could really take this information and be able to be confident in their monitoring of their children and really confident in voicing any concerns that they see. DR. GEPHART: Right. STEPHANIE: So I think it’s great. DR. GEPHART: The challenge is that really statistically you’re not going to have a lot of kids get NEC. Even in a high rate NICU, you’re going to have a lot of babies who don’t get it, and a few babies who do. But the outcomes can be so devastating for those few babies. So the simple part is really important, and the other question is do the interventions of NEC Zero affect other outcomes? And really, the answer is yes, because interventions are things like human milk standardized feeding protocols, antibiotic stewardship—those things are good for any baby— STEPHANIE: Right. DR. GEPHART: Any baby! So the good thing is that any NICU clinician can implement those things with relative confidence. Now, the big wildcard here that people don’t agree to consistently is holding feeding during transfusion. So that piece is a little bit controversial, actually it’s a lot controversial right now, but that component—the health system I’m working with has already adopted a practice to do that, so that is part of our bundle, and we’re going to keep it that way, but as we get into the literature about transfusions and NEC, it is somewhat controversial, and the evidence is not really conclusive. STEPHANIE: Right. We actually had an episode with a Dr. Hussain from Connecticut Children’s Medical Center, and in his conversation about transfusion associated NEC, he had mentioned GutCheckNEC. So it does seem to sort of all circle around. DR. GEPHART: It does, and the thing with GutCheckNEC is that transfusions is a risk factor. So in our structured communications protocol, which is coupled with GutCheckNEC, understanding the context of if a baby has been transfused in the last 48 hours, that’s a trigger. STEPHANIE: Right. DR. GEPHART: So those two pieces put together do heighten our awareness of what a baby could be at risk for. STEPHANIE: This was a really great conversation, Sheila. I really appreciate you sharing all of this. A lot of this, even though I have done a lot of research myself is pretty new in this context to me. So I think it really sort of simplifies some really complicated information. So I appreciate you sharing this with us. DR. GEPHART: Well, it’s been my pleasure and honor to try to simplify things. I have to do that for my own brain. I will say that this is an audacious goal. STEPHANIE: Right. DR. GEPHART: People look at me cross eyed when I say NEC Zero. They think what are you talking about? Is that possible? But I will tell you that there are a handful of NICUs across the country who are getting to zero with their NEC rates, and they are models. STEPHANIE: Right. DR. GEPHART: The things they consistently do are they prioritize human milk feeding, it is critical, they use standardized feeding protocols, they start feedings early with trophic feedings, which is just small feedings, and they generally have a fairly specific approach to handling transfusions and feeding. So those things are very important. But the human milk is essential. STEPHANIE: Right. Right. So before we wrap up, is there anything else with regard to NEC or your research moving forward that you would like to share? DR. GEPHART: I appreciate that offer. I would like to just emphasize how we do have evidence. We have pretty good evidence about things that prevent NEC. Now, does that mean that we’re going to prevent every single case of NEC? I don’t know that yet. STEPHANIE: Right DR. GEPHART: But we have pretty good evidence, and one of the things that’s pretty controversial in our country right now is the use of probiotics. I don’t know if any of your experts have gotten into that realm yet, but- STEPHANIE: We’ve touched on it and they’ve sort of said the same thing you did that it is sort of a controversial topic because if I’m saying this correctly, the FDA regulations and the procedures around that, but I know in other countries that they have seen reduced rates of NEC with probiotics. DR. GEPHART: Right, right, and that is one thing that I would say is certainly controversial. There is one of the NICUs that I’m aware of that uses probiotics. They’ve been at zero for like six years. One of the issues we have, I’ve spent a lot of time lately understanding the strength of evidence for all of these components that prevent NEC, we don’t have randomized control trial evidence for most of them. But we have 24 randomized control trials that show a decreased risk for NEC with probiotics—thousands of babies—thousands, and even some people will say the preparations are different in these different studies, there is a recent study that actually pulled the results from just a certain type of probiotic and they still showed benefit. So the issue here we have in the United States is that probiotics are marketed as a food product. And so as a food product, their regulation is different with the FDA than as a medicine. STEPHANIE: Right. DR. GEPHART: However, I think parents should know this, frankly. STEPHANIE: Right. DR. GEPHART: I think this is one of those opportunities for shared decision making in the NICU where a physician, a nurse practitioner could bring up this issue with parents to say hey, look, we have this opportunity to give your baby probiotics and this is what is available, this is the evidence, this is the risk. See, this is shared decision making. STEPHANIE: Right. DR. GEPHART: You go and you have a test, your physician or nurse practitioner would say this is how you have to decide what’s important, but I think NICU parents are very, very smart people, and I think we’re at the point in the United States where it is time to open up the conversation about probiotics to make it a joint decision versus an “oh, we’re just not going to do it”. STEPHANIE: Right. DR. GEPHART: Because we have such strong evidence, it’s just that most of those studies were not done in the US. STEPHANIE: Right. DR. GEPHART: However, there are many things that have been developed in other countries that we can adopt. The other issue is a standard formulation, a safe, standard formulation. There was a case of sepsis a few years ago that was very concerning—that’s severe widespread infection in a premature baby. That is the risk. So that’s what the clinician would say to the parent. But it’s very, very small risk if you look at all of the benefits. STEPHANIE: Right. DR. GEPHART: So I’m not going to pretend we should be using probiotics, but I do think that parents need to start asking for them. They need to start asking why are we not using them… STEPHANIE: Right. DR. GEPHART: ..because we have such strong evidence. So we have actually stronger evidence for probiotics than we do for antenatal steroids or Surfactant. Those are common, important, consistently delivered interventions for NICU babies. But you have risks, and that’s the issue. STEPHANIE: Right. DR. GEPHART: So we’re at a place for decision making. STEPHANIE: Right. And actually ironically, or maybe not ironically, I know that my boys did get probiotics, and that was five years ago that they were born. DR. GEPHART: That is ironic. STEPHANIE: We had an anomaly with Morgan. Nobody can sort of figure out why he got NEC when he did, but we did do all of the sort of standard care practices, probably even advanced practices for five years ago, and we had one that got it and one that didn’t. So…but knowing now what I have learned is they were doing the very best practices at the hospital where my sons were born. So I think we were at the right place at the right time and had the best outcomes that we could hope for. DR. GEPHART: That’s awesome. That’s awesome. Did you feel like with Morgan that they were able to recognize it pretty fast and act? STEPHANIE: I really think they did. I think that is probably the key that saved his life because he developed NEC at four days old and had really only had two trophic feeds, and it was colostrum. DR. GEPHART: Okay. STEPHANIE: Actually after the conversation that I had with Dr. Hussein, I went back and looked and he did not have a blood transfusion within that timeframe, so he sort of, it’s my understanding he’s just sort of an anomaly, but that’s why we’re looking to the researchers to piece together all of these things. That’s sort of what drives me is he doesn’t easily fit into something that could have, should have, would have, maybe been different and that seems to be the riddle that’s NEC. DR. GEPHART: Sure. There’s an analogy for this it’s called, a wicked problem, I don’t know if you’ve heard of that term, but you were at my talk when we were in Connecticut,… STEPHANIE: Right. DR. GEPHART: ..and I talked about the wicked problem and how it’s like a forest fire, it’s not easily solved. There’s a lot of pieces to it,… STEPHANIE: Right. DR. GEPHART: …and I think NEC is really the neonatal wicked problem. STEPHANIE: Right. DR. GEPHART: So I’m so glad that Morgan got care so quickly and got such excellent care. And that’s the thing is that clinicians, physicians, dieticians, lactation consultants, nurses, nurse practitioners, they want to do the absolute best for your baby. STEPHANIE: Right. DR. GEPHART: Nobody has ill will. This is a team effort, but they’re human, and that’s the thing with wicked problems… STEPHANIE: Right. DR. GEPHART: ..is that you have humans operating in these complex systems, and trying to deal with things and what we know with solving wicked problems, like forest fires, it’s a combination of boots on the ground, and standard protocol. STEPHANIE: Right. DR. GEPHART: So it’s the strength and protection of both approaches that really is effective, maybe not taking away completely the wicked problem, but at least confronting it. STEPHANIE: Right. DR. GEPHART: So I’m so glad that Morgan got such great care. STEPHANIE: Thank you. We are too. We are too. And like I said, I think it goes to show that I’ve heard multifactorial used and all kinds of big words with regard to NEC, and just knowing that there are researchers out there like yourself who are trying to distill this information and simplify it for parents and practitioners as well that this is one of the ways that I think we will get to zero NEC. That’s our goal as well. So I really appreciate you talking to me today, and would love to talk to you again, and any of these links when the website is up, would love to share. So thank you! DR. GEPHART: Absolutely. It would be my honor to share those. It’s been fun to be with you. STEPHANIE: Thank you. You too. Direct links to more information about the GutCheckNEC can be found in this episode’s show notes. In closing, I’d like to share a few thoughts about today’s conversation with Dr. Gephart. Simply put, information is power. I believe that a risk assessment like GutCheckNEC can empower parents in the NICU by distilling complex medical information, and presenting it in a simplified, and actionable way. Morgan was diagnosed with NEC at four days old. My husband and I were still in shock, and hadn’t even begun to come to terms with our twin sons’ unexpected and traumatic birth, when Morgan was transferred to another hospital and underwent emergency surgery. In the days and weeks that followed, I diligently called two NICUs every morning after rounds for updates on our two babies. I took copious notes to share with my husband on weight gains, Oxygen levels, and whatever else each nurse made mention of during the phone calls. And during our daily visits, we spoke with each baby’s nurse personally about all of the day’s happenings. Since then, I’ve learned a lot more about prematurity and NEC. And if we were in the same situation today, I would have a lot more questions to ask about all areas of our babies care. In retrospect, I realize we didn’t know what questions to ask. We took our lead from the nurses, and we looked to them to tell us what we needed to know. GutCheckNEC presents parents the opportunity to learn what questions to ask about NEC. Objectively. And, proactively. And, it can help open up the dialogue between parents and caregivers in advance of potential crisis. Show your support for our smallest and most fragile babies, those who have the greatest risk for developing NEC. Show your support for continued research in NEC. And join our effort to raise awareness about, and funds for research in NEC by making a donation to Morgan’s Fund at morgansfund.org/donate. If you’ve had a personal experience with NEC and would like to share your story, or have a question or topic that you’d like to hear addressed on our show, e-mail us at feedback@morgansfund.org. We’d love to hear from you! Additional Information You can make a donation directly to Dr. Gephart’s research in NEC at the University of Arizona College of Nursing by visiting https://www2.uafoundation.org/NetCommunity/SSLPage.aspx?pid=341 You can become a donor to the College of Nursing by visiting http://www.nursing.arizona.edu/giving/leave-your-legacy Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. The opinions expressed in Speaking of NEC: Necrotizing Enterocolitis (the Podcast series) and by The Morgan Leary Vaughan Fund are published for educational and informational purposes only, and are not intended as a diagnosis, treatment or as a substitute for professional medical advice, diagnosis and treatment. Please consult a local physician or other health care professional for your specific health care and/or medical needs or concerns. The Podcast series does not endorse or recommend any commercial products, medical treatments, pharmaceuticals, brand names, processes, or services, or the use of any trade, firm, or corporation name is for the information and education of the viewing public, and the mention of any of the above on the Site does not constitute an endorsement, recommendation, or favoring by The Morgan Leary Vaughan Fund.

Laura Martin. Photo courtesy of Laura Martin. Episode 6 features Laura Martin, expert parent, mom blogger at Joseph at Home, and the Director of Parent Communication and Engagement at Graham’s Foundation—a non-profit organization that supports parents of premature infants. During the episode, Laura shares her son Joseph’s story of prematurity and survival including his near fatal bout of late-onset NEC and the multitude of life-long complications that have resulted. She discusses: The extremely premature birth of her twin sons, Joseph and Campbell, at 24 weeks—four months early, and Campbell’s passing at 23 days of life, How Joseph developed late-onset NEC and lost two-thirds of his small intestine, Several of Joseph’s secondary diagnoses including Short Bowel Syndrome, Auditory Neuropathy Spectrum Disorder, Eosinophilic Esophagitis, and multiple food allergies—all resulting from NEC, How hers and her family’s experience with prematurity led to her work at Graham’s Foundation, Her personal blog where she documents her daily life as an expert parent of a child with special needs. Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. This episode was produced in part by the TeacherCast Educational Broadcasting Network. [powerpress] STEPHANIE VAUGHAN, HOST: Welcome to Episode 6 of Speaking of NEC—a free, audio podcast series about Necrotizing Enterocolitis. Produced by The Morgan Leary Vaughan Fund, and funded by The Petit Family Foundation, Speaking of NEC is a series of one-on-one conversations with relevant NEC experts—neonatologists, clinicians and researchers—that highlights current prevention, diagnosis, and treatment strategies for NEC, and the search for a cure. For more information about this podcast series or The Morgan Leary Vaughan Fund, visit our website at morgansfund.org. Hello, my name is Stephanie Vaughan. Welcome to the show. I’m the Co-founder and President of The Morgan Leary Vaughan Fund. NEC is the leading cause of Short Bowel Syndrome or Short Gut Syndrome. The amount and location of intestine lost can result in life-long medical complications. Up to now, we’ve discussed NEC and its most common complication from the perspective of the neonatologist or surgeon. However, I feel that it is equally important to share the parent’s perspective. I’m privileged to have one such expert parent as my guest today. Laura Martin is the mom blogger at Joseph at Home, and the Director of Parent Communication and Engagement at Graham’s Foundation. She is also the parent of a fellow surgical NEC survivor. Laura will share with me today her son Joseph’s story of prematurity and survival including his near fatal bout of late-onset NEC and the multitude of life-long complications that have resulted. During our conversation, she will discuss in varying degrees: The extremely premature birth of her twin sons, Joseph and Campbell, at 24 weeks—four months early, and Campbell’s passing at 23 days of life, How Joseph developed late-onset NEC and lost two-thirds of his small intestine, Several of Joseph’s secondary diagnoses including Short Bowel Syndrome, Auditory Neuropathy Spectrum Disorder, Eosinophilic Esophagitis, and multiple food allergies—all resulting from NEC, How hers and her family’s experience with prematurity led to her work at Graham’s Foundation, Her personal blog where she documents her daily life as the parent of a child with special needs. With that in mind, let me introduce my guest today. This is Laura. Hi, how are you? LAURA MARTIN, GUEST: Hey, good. How are you? STEPHANIE: Good. Thank you for joining us. And Laura is a blogger at Joseph at Home and the Director of Parent Communication and Engagement at Graham’s Foundation. So I will let you introduce yourself and talk to me a little bit about your experience with prematurity and Necrotizing Enterocolitis. LAURA: Yeah. Our twin boys were born at 24 weeks gestation on Halloween morning in 2009. It came as a big surprise. It had been a perfectly clean, normal pregnancy. I had just had an appointment three days before, woke up with a dull backache about midnight. And Joseph was born first at 7:41 and his twin brother Campbell at 7:42. No rhyme or reason for the prematurity. It just happened. Campbell, unfortunately lost his battle to prematurity after 23 days of life. He just had a lot of complications from prematurity that he just couldn’t have overcome. Joseph went on to spend 228 days in the neonatal intensive care unit before he came home. He is now five and a half. He just started kindergarten. But it’s been a long journey to get here. We were two days from coming home when he was 5 and a half months old. He was about eight weeks adjusted. We had everything set up at home. We had oxygen. We had G-tube equipment. We had everything. We were ready. His room was ready. All of the clothes were washed. Two days before discharge, we got a call from the NICU that he was gray and bloated. And they were putting him on a ventilator. Let me back up a little bit. A few days prior to that, he had been showing some signs of infection. But nobody really knew what it was. He just had vaccines. He was running a little bit of fever. We contributed it to that. This pushed discharge back a little bit. But just two days before the initial discharge, when they called and said he’s gray and bloated, and they were putting him on a ventilator. You need to get here immediately. Our world kind of turned upside down, because we thought we were two days from home. And here we were not knowing what was going to happen. This was a Saturday, the day before Palm Sunday, 2010. And we didn’t know what was going to happen. The doctors kind of watched him throughout the Saturday, were taking X-rays every few hours. A little bit after lunch that day, one nurse practitioner came and said, his X-ray looks a little bit like NEC. Do you know what that is? And we said, of course, we know what that is. We’ve been in the NICU five and a half months. But he’s eight weeks adjusted. Why would be looking at NEC? We’ve been told once you get to your due date, you cross that off your list of things to worry about. And so, as the day went on, the night went on, it became very evident that he had Necrotizing Enterocolitis. They had seen this one other time in the NICU with a baby this old. He went through Saturday night. Things were not looking good. And on Sunday morning, the surgeon came to us and said, I’m going to take him to the OR. I’m going to open him up. And I’m going to see what happens. We don’t know what we’re going to find. So, on Palm Sunday, 2010, the surgeon took him to the OR. He was gone for several hours and came back halfway through surgery and sat us down in a room and said, here’s what I found. He has 41 centimeters (16 inches) of salvageable intestine. He said, he has 28 centimeters (11 inches) below his stomach, and he has 13 (5 inches) above his colon. Everything else in the middle is completely gangrenous. He said, we can take out the gangrenous intestine. And he’ll have two stomas for a while. Then we’ll go back in and reconnect. But he also looked at us and said, we don’t know what life for him is going to be like. It’s probably going to be very rocky. He may die before the age of two waiting on a liver transplant, because he’s going to be TPN dependent. If you want to close him up and let him go, I’ll respect your wishes. And, of course, we looked at him and said, no way, we’ve gotten this far. We’ve already lost one kid. We’re not doing this again. Go in there. Do what you have to do and save his life. So he went back. He was gone for several hours, came back to us. We saw Joseph, and it was amazing. Even though he had stomas, and he had just lost two thirds of his small intestine, he looked so much better than he had right before he went, because the infection was gone. A few days after that, they went in and placed a central line, because he was, of course, totally TPN dependent. He already had a G-tube before NEC, because of aspiration to his lungs. So we were fortunate with that that he already had the G-tube. But, as the weeks wore on, they were able to slowly decrease TPN, increase feeds, and decided after four weeks, he was ready for intestine reconnect, which was shocking. Nobody expected after four weeks he would be ready for intestine reconnect. So four weeks later, they went in, reconnected the intestines, told us we would probably be in another two to three months. He again amazed everybody—came off TPN very quickly, increased G-tube feeds to the point that they pulled his port before he came home. He never came home with a central line. And four weeks after his reconnect surgery, he came home—after 220 days in the NICU. STEPHANIE: That’s amazing. LAURA: So that’s how NEC came to be. Again, the hospital had seen one case of that. And it had been years and years and years. And people say, are you sure it’s NEC? Are you sure it was NEC? Yes, pathology confirmed that it was NEC. But who knows? Who knows why he had it at five and a half months old. STEPHANIE: Right, right. So just to back up, I’m curious what you knew about NEC before his surgery. You know, you had said that you had been in the NICU for now almost five months. And he reached his due date, so you were crossing it off the list. So I’m just curious, in general terms, what you knew up to that point. LAURA: NEC was one of those things that I remember learning about really early on in our NICU stay. Having 24-week twins, we knew that it was a very rocky journey. They both had less than 50% chance of survival. But my husband and I were the type that we wanted to know everything. We wanted to know what are things we have to look out for. What are things we need to be worried about? What are things that we don’t have to worry about? And it was within the first 24 to 48 hours that the nurse said there’s a thing called Necrotizing Enterocolitis. It doesn’t happen a lot. But it’s one of these things we watch for. We stay on top of it. So we knew about it from the beginning, but we had always been told that once you reach the gestational due date, you didn’t have to worry about it anymore. And while that is so true 99.999% of the time, there is a very small chance that it can happen later. And it’s almost one of those things I wish we had never been told—oh, yeah, you don’t have to worry about it when you hit 40 weeks. Because we did—we had completely crossed it off Right. So we know about it. And we knew what the warning signs were. We knew what to look for. Yet, again, when we look back on it, he had some of these warning signs two to three days before he got really, really sick. But why would—none of us thought it could be NEC. We thought, well, he’s had some GI issues. He has the feeding tube. He’s had his vaccines. It could be any other bug he’s picked up. He’s still in the NICU. But we knew what it was, but it was still just a huge shock that—I mean, he was 13 pounds at that point. He was a big kid, you know, for being in the NICU. STEPHANIE: Right, right. So he came home now, you said, four weeks after he had been reconnected. So talk to me a little bit about, I guess, those first days and first months when he was coming home—you know, again, sort of thinking from the perspective of things that we want to let parents and caregivers know, questions to ask, sort of things to look out for—so anything that you want to talk about, you know, his transition home and getting settled. LAURA: Yeah, he came home on complete continuous feeds via G-tube. So he was on feeds 24 hours a day because, of course, having NEC left him with short bowel syndrome. So he had a lot of dumping episodes, where it was out of control at times. We couldn’t really go anywhere because of the dumping syndrome. As the days went on, the weeks went on, the months went on, that got a little bit better. We were in and out of GI every 8 to 12 weeks, just checking in, making sure he was gaining weight. But a lot of doctors also didn’t really know what to do because he wasn’t TPN dependent. A lot of kids who come home with short bowel syndrome are TPN dependent. But here you have this kid who has only a third of his small intestine, but for the most part he’s tolerating formula well. He’s tolerating G-tube feeds. He’s gaining weight. He’s not going to need a port. Everybody was convinced he would have to have his port put back in. He never did. So that was actually, to be honest, a frustration for the first several years, is finding doctors who understood that, yeah, he is doing well. But he’s also not doing well. He only has a third of his small intestine. His weight gain is very slow. He still has periods of severe pain even today, from school. He still has periods where his belly is very distended. It took some time to find doctors who really wanted to help and say, yes, there really is still a problem here—with a kid who only has a third of his small intestine. That first year that he was home, he was rehospitalized five or six times, most of those with a GI bug. If he got any sort of stomach bug, we were in the hospital, because his body just couldn’t handle it. And so we were back in. Usually it would lead to a respiratory infection. He would spend a good week, 10 days, in the hospital. That was the first year. After that, I quit my job teaching, because we knew he had to stay home. He had to be healthy. And he had to grow. And as he’s gotten bigger, he’s gotten healthier. He has not been in the hospital for a GI bug in 3 and 1/2, 4 years. It’s been awhile. STEPHANIE: Oh, that’s great. LAURA: Yeah, now his body can tolerate it. You know, it’s not pleasant still. But we know what to do. But, as he’s gotten bigger, it’s gotten better. So, yeah, that was the first few years out of the hospital. STEPHANIE: We don’t have nearly the after-effects, but I remember Morgan’s transition home was pretty chaotic. LAURA: Yeah. STEPHANIE: His brother came home after 85 days, and I’m guessing was a much simpler transition, even just holding him in hands-on care and changing diapers. Morgan was very traumatized, I think, from being in the hospital and having the surgery. And we saw a big, big difference between him and his brother. So it was very scary as a parent that even simple things that you have to do was traumatizing to him. LAURA: Right. And then they can’t communicate with you to tell you that. And that’s what was so hard to watch early on, was you knew he was hurting. You knew he was in pain. But I didn’t know what to do to help, you know. So that was hard. Yeah. STEPHANIE: So, I guess, now that he’s getting a little bit older—you said he started kindergarten. That’s great. So how is he doing, I guess, developmentally? And are you seeing anything—you know, secondary diagnoses, I guess, maybe, strictly because of NEC or because of the short bowel or other issues that he’s having? LAURA: Yeah, he has several things that are going on. He did just start kindergarten. He’s in a special needs kindergarten. As a result—well, when he had NEC, he had to receive Gentamicin, which of course is an ototoxic drug. And the surgeon said, if we give this to him, he will probably lose all of his hearing. But if we don’t give this to him, he’s not going to live. Well, of course, it was a no-brainer decision. Before that, he had not passed his newborn hearing screening. But a lot of preemies don’t. So we kind of thought, well, we’ll get out of the NICU, he’ll pass it. He never did. While he was still in the NICU—this was in between NEC and the reconnect surgery—he was diagnosed with Auditory Neuropathy Spectrum Disorder, which is a hearing loss that comes and goes. It’s almost like you’re trying to tune a radio and there’s static. And that was what his hearing was like. So he received his first cochlear implant when he was three—three months after he turned three—because his hearing was rapidly deteriorating in his left ear. Just, not even two weeks ago, he received his second cochlear implant in his right ear. And we always go back to say, his hearing probably would have never been that great. But it’s definitely a lot worse post-NEC, because he had to receive the Gentamicin, the ototoxic drug, in order to kill the bacteria. Some other things that he has—July of 2014, he was diagnosed with Eosinophilic Esophagitis, which has been in question for several years. And we could not get the GI doctor to agree to do an endoscopy. He hated to do the endoscopy, because it meant putting him under sedation. Due to asthma, he didn’t want to do that. But at the same time, we’re battling with this increased amount of food allergies, knowing that that has to be a problem. Finally, they agreed to do the endoscopy. And it was clear that he had Eosinophilic Esophagitis. As a result of that, he has 15 food allergies. I’m happy to list them all if you want. But it includes all of the top 8 plus beef, chicken, rice, potatoes, watermelon, strawberry, pineapple, and a whole slew of medications. And I always tell people asking—it’s hard to know whether he would have had that regardless. Probably not. But having the Short Bowel Syndrome made it worse. He would not have had Short Bowel Syndrome if he didn’t have Necrotizing Enterocolitis. So to me it’s all sort of related. STEPHANIE: Right. Right. There’s definitely a domino effect. LAURA: It’s a domino effect. One thing has led to the other, which has led to the other. So it’s hard to know, some days, if you’re battling GI issues because of Short Bowel Syndrome. Or are you battling GI issues because of the Eosinophilic Esophagitis? Or are the white blood cells growing because he’s eating something he’s allergic to? Is there a new allergy? So some days we really struggle knowing what is what. And then you’ll have periods where he does great. And he’s like a normal kid. He does still have a G-tube. We were told he would lose the G-tube by two. But here we are almost six, and we still have the G-tube. Many days I wish we didn’t. But there are many days we couldn’t do without it. And if he doesn’t feel like eating or he’s in pain, we have the G-tube. And it’s literally been a lifesaver. And if he’s been sick, we can always get fluids in him. I would love to see it go. But I don’t see it going any time in the future. He doesn’t know life without it. He’s had it since he was four months old. To him it’s second nature. He gets his G-tube feeds at school. He gets them at home. They travel with us. But it’s truly a lifesaver for him. But it helps him gain weight. It’s what helps him actually be on the growth chart as a short-bowel kid. Many short-bowel kids, I think, are failure-to-thrive. He has never even been remotely considered failure-to-thrive, which is huge. So, yeah, there’s a lot of complications as a result—what I feel like, had he not had NEC, wouldn’t have led to X, Y, and Z probably. He does have development delays. But a lot of it is that he spent so much time in the hospital. Then there was the hearing issue, but he could not get a cochlear implant because he wasn’t healthy enough to have surgery. So it was just sort of this domino effect, and a spiral of getting out of it, and getting him healthy enough to be able to have surgery. And then you’re trying to catch up. You’re trying to catch up with language, fine motor, gross motor, it all, as well. But the kid we were told would never walk or talk, walked into kindergarten last week. So there’s so many things to be thankful for, and so many things that he’s doing so well on, that those are the days you really have to hold onto on the days he’s feeling really, really bad. You have to know that he’s going to get through it. Life will turn around, and it will get better. It’s just going to be interesting to see as he continues to grow, how much of this is just going to continue to get better. Will there be a decline at some point? We don’t know. Nobody really thought he would even make it to this point. STEPHANIE: Now, I’m just curious, sort of, personally, but also as a fellow parent of a NEC baby, have you talked to him at all about being in the NICU? Has any of that come up yet? I mean, I know he’s still sort of young. But I’m just curious. LAURA: Yeah, he knows he was in the hospital. When we drive by the hospital where he was born, he’ll say, that’s where I was born. That’s where my sister was born. He has seen pictures. He’s seen videos. But I don’t think he quite cognitively wraps his head around it. When he had a cochlear implant put in 10 days ago, it was at the hospital where he had NEC. And so we were able to kind of say, you were in the hospital here when we are a baby. A couple of the nurses stopped by to see him—they took care of you when you were a baby. But the cognition is just not quite there too. He sees his pictures. And he’ll say, I was very sick. And, yes, you were very sick—because he knows that his baby pictures look very different from his sister who was born full term. So he knows. He knows he has a G-tube. She does not. And so he’s starting to really realize those differences. STEPHANIE: Right. Yeah, I don’t think we’ve quite reached that yet. Shaymus deals with asthma. So he gets his puffs and he has, you know, different things. But I don’t think they’ve really lined up and taken notes on, you know, your picture has this. And my picture has that. Or you have this and I have that. But, yeah, sort of, it’ll be interesting to talk to them about it when they start to ask. Like, they just figured out that they’re twins this year. LAURA: Oh, that’s so funny. And my husband and I have talked about it. Gee, at what point in their life are they going to realize everything that they went through as a baby. And all these odds that were stacked against them. And all the times that they shouldn’t have lived. And will they be teenagers? Will they be adults? Will it be when they have their own children? My husband and I talk about this a lot. It’s just going to be interesting to see at what point do they kind of go, oh, wow, yeah, that really was what mom and dad went through and what I went through. It’s just fascinating. STEPHANIE: Yeah. So I would also like to let you talk about the work that you’ve done now because of having preemies and Joseph’s diagnosis. So you are the Director of Parent Communication and Engagement at Graham’s Foundation. So I’m happy to let you plug them away, and also to talk about your blog, which is Joseph at Home. LAURA: Yeah, I'll start with Graham’s Foundation first. I started working for them, gosh, about three and a half years ago in a different capacity. And it was one of those things that I was staying home with Joseph. And I was trying to figure out a way that I could give back to the preemie community. But I knew I couldn’t go into the NICU, because here I was with this child who got sick easily. And I knew that that couldn’t happen. So I started working for Graham’s Foundation, which was such a great outlet to be able to connect with other preemie parents, and sort of share stories—share stories with families who lost their child, with families who went through a long-term NICU stay, families who went through a short-term NICU stay. People will say, well I was only in the NICU 10 days. You were in seven and a half months. One day is one day too long for anybody to be in the NICU. And that’s what I always say to people. Nobody should have to go there. And if I can provide any sort of “it’s going to be OK,” I would love to do that. And so now, I serve as the Director of Parent Communication and Engagement. I do a lot of the writing for the blog for Graham’s Foundation, which is something we’re really trying to get off the ground. And through that, I also serve as a NEC mentor. So if parents come across our website and are looking to talk with someone who has experienced NEC, in no way am I a medical professional but I'm able to say: This is what we experienced. This is what we’re experiencing now. These are some questions you might be able to ask the doctor. And it’s been really nice to connect with people. Also, being five years out, to say, I promise you are going to get through this. When you’re dealing with, all along, doctor’s appointments, and you feel like you’ve got 18,000 things going on in one week. I’m here to tell you that I promise you, it gets better. The appointments get less and less and less. And it’s been so nice to connect with parents, and to offer that support from home, while I can still stay home with my kids and be able to work from home. And then also I have my personal blog, josephathome.com, which I started when I found I was pregnant with twins. I didn’t even share the blog address with anybody. My husband and I thought, oh, this will be great. We’ll update it. We’ll send it to friends and family. So as the pregnancy rocked along, I would sort of update it. I could never send out to anybody. And then when they were born Halloween morning, 2009, at 24 weeks gestation, I knew I didn’t have the energy to tell the same story over and over and over about what was happening. The texts were too long to send the information of what was going on. We had two of them, and I just couldn’t do it. And I was, like, oh, I’ve got this blog. This will be a great way to update people, so the long days of sitting in a hospital, my husband worked on our family tree. And I worked on the blog. That is just what we each sort of did to take our mind off of what was going on. And it was a great way, if somebody asked me a question, I would just say, read the blog. It’s on the blog. Just read the blog. I could share pictures—it just—because I wasn’t really in the mood to talk. We would talk to family, immediate family, and share with them what was going on. But it was just—it was so draining to tell the same story over and over and over. And if I just wanted to get something out there quickly, I would put it up. So, when Joseph came home, and I thought, well, I’ll keep it going. We’ll see what happens. It’ll probably die by the wayside. Well, five and a half years later—it’s almost six years later—it’s still going. And I write a lot now just about, of course, about prematurity, but also raising a special needs child and what that looks like, because we’re in this short-bowel world. We’re in the eosinophilic world. We’re in this hearing-loss world. We’re in the cochlear-implant world. We’re in the vision-impaired world. We’re in the mild cerebral palsy world, food-allergy world. And it’s just been nice to be able to connect with other parents and just to write about our real life and what it’s like. What it’s like. How do we deal with insurance? How do we deal with medical supplies? How do we travel? How do we do this, that, and the other? And it’s just a great outlet, too, just for venting, you know. And if I don’t want to talk about it, I can write about it. So we’ll see where it goes. It’s been a really nice outlet. But it’s also a great way to show Joseph, hey, this is where you started. This is where you are now. And it’s almost like a scrapbook, really, of his entire life, because it started the day he was born, and has everything. I just hit my—over 1,100 entries on it. STEPHANIE: That’s great. I commend you on that. I attempted, when I first came home from the hospital, to start recording things. And, I think, honestly, it was just too hard. I sort of thought to myself, I don’t want to remember this piece of it, so I sort of stopped. And I had scraps of paper where I would write down stats every day. You know, they gained this, and literally had, like, a pile two inches thick, by the time they came home, of daily weights and charts and things. Yeah, I mean, I’ve seen many of your posts. And I think they’re great. And I think it’s a great outlet. And, again, sort of that you’re not alone. And, you know, people are better off than you. People are worse off than you. And everybody’s sort of on their own journey. And I know preemie parents tend to minimize amongst other people, but your struggle is really your struggle and your family’s struggle. And no one should have to struggle. LAURA: No. And that’s what I’ve always said to people is, somebody out there always has something worse going on. Like, on Joseph’s worst day, somebody else has something worse going on. And that’s what I always say to people is, yeah, this is just our life in a little nutshell. But we’re so thankful for what we have. And, again, it could always be worse. You can just turn on the news every day and see that. But if it’s just, you know, if it can help one parent to say—and even sometimes I think people don’t like to say, well, this is not fair. You know what, sometimes it’s not fair. And it’s OK to say that and have a little pity party and then move on. And I enjoy being able to say to people sometimes. STEPHANIE: That’s great. So, I guess, is there anything else that you would want to mention if you had somebody in your position, however many years back, thinking to ask the doctors about, or transitioning home—coming home—how you sought out your specialists, if you’re not getting the answers that you think you should, how you proceeded, any sort of big-sisterly advice. LAURA: Yeah, I know, really. I think the big thing is to trust your instincts if you know that there’s something not right. We’ve gone through our fair share of doctors. Because if I feel like my child’s not getting the care that they need—and any parent would feel this way—I’m not going to settle for mediocre. I’m not going to settle for “he’s going to be fine” when you know in your heart that there’s still a problem. We were having some issues last year around the whole eosinophilic diagnosis. And I felt like we had run out of options where we live. And so I reached out to a doctor eight hours away. And he said, if you’re willing to travel, I’m willing to see him. I said, of course, we’re willing to travel. And so we did. He got us in. And we made the trip. And it was so nice to just connect with somebody who was a specialist in that field of Short Bowel Syndrome, to be able to say, yeah, he’s doing OK. I see that there are some problems. But you’re doing the right thing. And I think that’s become sort of my mantra is, don’t stop until you have the answers that you need. And there may not be answers. But I am not going to rest until I know that we have the answers we need. Like, we’re having some eosinophilic issues, so we’re working on getting into a top eosinophilic clinic. I don’t care how far we have to travel, because that’s what Joseph needs and it’s what’s best for him. And that’s what matters. It matters him feeling good. It matters him being healthy. It matters him growing. And he deserves to have the best life absolutely possible. And that’s what I would tell somebody if you’re just coming home. If you feel like something is not right, keep going and keep going and keep going. Yes, it’s exhausting. I think there are many days I’m asleep before my head even hits the pillow. But you have to do what’s best for your kid, because they can’t do it for themselves. You are their advocate. And that’s one thing that the NICU nurses taught us really, really early on—is you have to advocate for your child. Nobody else is going to do it for you. They can’t do it for themselves. You just have to keep going. And, again, it’s hard. You may hit brick walls here and there. Because goodness knows we’ve had our fair share with doctors. And it’s OK with doctors to speak your mind and say, you know, I don’t think you’re right on this. I think there’s more to it. You may upset them a little bit, because there’s no doubt I’ve upset a few. But it’s OK. It’s OK. Yes, they’re doctors. But they don’t have all the answers. You’re the parent. You live with your child day in and day out. You know their idiosyncrasies. You know what’s right and what’s wrong with them. And I think standing up for yourself is so important. And that’s what I would tell somebody coming out. You can’t be shy when it comes to advocating for your child who has special needs. STEPHANIE: I would agree. Yeah, we’re transitioning through preschool. And the boys were kindergarten eligible this year. But they’re actually being given an extra year of pre-K. And we had sort of that, uh, I’m not sure about this. I’m really not sure about it. I’m really not sure about it. And in the end they saw that—their teachers agreed with us. And the educational system agreed that, yeah, they’re a little bit immature. And probably going to kindergarten isn’t the best idea for them. And they really need the extra year. You know, they’re smart. Yes. But good enough isn’t good enough. We don’t want them to sort of eke by. We want to give them the best opportunities that they can have. So I agree with you wholeheartedly. LAURA: And it’s tough as a parent. I’ve had this conversation with a lot of people. My husband’s a teacher. I’m a teacher also. I’m not teaching right now. Hopefully one day I will be again. But it’s hard as a parent. It’s hard as a parent-teacher to have a child who has special needs and who needs that IEP (Individualized Education Program). It’s tough to sit on that end of the table as a parent. I mean, I’ve sat on the other end of the table as a teacher countless times. But, as a parent, it’s a tough pill to swallow, to say—and we know—I mean, Joseph started kindergarten. But we know full well he may need to repeat kindergarten. And while that’s tough to say, it’s a reality. We hope that he does great. But he may need to repeat. And if that’s what’s best for him, then that’s going to be what’s best for him. It’s tough to sit in an IEP meeting and hear how far behind he is. Or these are all the goals. And up to 21 pages now of his IEP. But it’s what he needs. And it’s what’s best for him. But I always go back to the day when one of our favorite NICU nurses—this was a long time ago—said, you know, one day he’s going to pull out a picture of him with all those tubes and wires and on a ventilator and say, see, mom, you remember this. And I have to think back to that, because, yes, it’s hard. And I kind of want to wallow in self-pity about, oh, I wish he was just in a regular ed class. He shouldn’t even be here. And that’s what I have to remind myself is, we had many days where we weren’t even sure we would see pre-K. And I know you’re the same way. We weren’t even sure he would see kindergarten. But here we are. And let’s just make the most of it. He’s loving every second of it. And that’s what matters. And so, being a preemie parent, as you know, it’s a journey that I never expected. But at the same time, I’m grateful for it, because it’s opened my eyes to a whole new area of life. STEPHANIE: Right. Well, I really appreciate you talking to me. And I think you’ve given some great advice—preemie parents or not, and NECs parents or not—on advocating for your child, and in every facet. So I really appreciate your time. And thank you so much. And if there’s anything else that you want to add, feel free. LAURA: If anyone wants to contact me personally, I’m happy to answer questions if there’s something that anybody wants to know more about. STEPHANIE: So great. Thank you. Thank you so much. LAURA: Thank you. STEPHANIE: For more information about Laura or to follow her blog, visit: josephathome.com. A direct link can also be found in this episode’s show notes. You can also email Laura directly at: laura [at] grahamsfoundation [dot] org. In closing, I’d like to share a few thoughts about today’s conversation with Laura. According to Dr. Besner, with whom I spoke about Short Bowel Syndrome in Episode 1, “if we estimate that a newborn baby has approximately 200 centimeters (78.74 inches) of intestine, they have to be left with at least 40 centimeters (15.75 inches) in order to be able to nourish themselves and get off TPN.” As a result of his bout with NEC, Joseph had only one centimeter (0.4 inches) more remaining. So first, I would like to take a moment to celebrate Joseph’s survival, courage, and strength. And that of his family. Both Joseph and his parents have shown remarkable resiliency while dealing with the daily effects of his bout with NEC. Second, I would like to reiterate that I strongly believe that a cure for NEC, once found, will have a far reaching impact not only on Gastroenterology (the digestive system and its disorders) as a whole, but also all of the patients like Joseph, and families like Laura’s. Show your support for our smallest and most fragile babies, those who have the greatest risk for developing NEC. Show your support for continued research in NEC. And join our effort to raise awareness about, and funds for research in NEC by making a donation to Morgan’s Fund at morgansfund.org/donate. If you’ve had a personal experience with NEC and would like to share your story, or have a question or topic that you’d like to hear addressed on our show, e-mail us at feedback@morgansfund.org. We’d love to hear from you! Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. The opinions expressed in Speaking of NEC: Necrotizing Enterocolitis (the Podcast series) and by The Morgan Leary Vaughan Fund are published for educational and informational purposes only, and are not intended as a diagnosis, treatment or as a substitute for professional medical advice, diagnosis and treatment. Please consult a local physician or other health care professional for your specific health care and/or medical needs or concerns. The Podcast series does not endorse or recommend any commercial products, medical treatments, pharmaceuticals, brand names, processes, or services, or the use of any trade, firm, or corporation name is for the information and education of the viewing public, and the mention of any of the above on the Site does not constitute an endorsement, recommendation, or favoring by The Morgan Leary Vaughan Fund.

Dr. Martin Lee. Photo courtesy of Prolacta Bioscience. Episode 4 features Dr. Martin Lee, Vice President of Clinical Research and Development at Prolacta Bioscience. During this episode, Dr. Lee provides a comprehensive overview of a 100% or exclusive human milk diet in the prevention of NEC in extremely premature babies, those weighing less than 1250 grams (2 pounds 12 ounces) and who have the greatest risk for developing the disease. He discusses: * His transition from the blood industry to Prolacta, which developed of the world’s first human milk-based human milk fortifier * What constitutes a 100% or exclusive human milk diet * The clinical evidence showing a 70% reduction in NEC, an 8-fold reduction in surgical NEC, and a 4-fold reduction in mortality through the use of exclusive human milk diet * The importance of safety in the breast milk industry, including Prolacta’s rigorous product testing and donor safety profiles which parallel blood industry standards. Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. This episode was produced in part by the TeacherCast Educational Broadcasting Network. [powerpress] STEPHANIE VAUGHAN, HOST: Welcome to Episode 4 of Speaking of NEC—a free, audio podcast series about Necrotizing Enterocolitis. Produced by The Morgan Leary Vaughan Fund, and funded by The Petit Family Foundation, Speaking of NEC is a series of one-on-one conversations with relevant NEC experts—neonatologists, clinicians and researchers—that highlights current prevention, diagnosis, and treatment strategies for NEC, and the search for a cure. For more information about this podcast series or The Morgan Leary Vaughan Fund, visit our website at morgansfund.org. Hello, my name is Stephanie Vaughan. Welcome to the show. I’m the Co-founder and President of The Morgan Leary Vaughan Fund. Today, my guest will be Dr. Martin Lee, Vice President of Clinical Research and Development at Prolacta Bioscience, which “creates specialty formulations made from human milk for the nutritional needs of premature infants in neonatal intensive care units.” Last October (2014), while attending the annual Preemie Parent Summit in Phoenix, Arizona, I had the pleasure of meeting Prolacta’s Chief Executive Officer Scott Elster. During our conversation, I was invited on a tour of the company. A few weeks later, along with a group of representatives from various preemie organizations throughout the country, I flew out California to tour Prolacta’s human milk processing facility, and to learn more about the people and research behind the company. I was highly impressed by all aspects of Prolacta from the manufacturing plant itself to the rigorous testing their products undergo throughout their processing. Even more impressive to me is the fact that everyone that we met at Prolacta has a personal connection to prematurity. The CEO himself is the parent of twins born prematurely. And, I was shocked to learn that one of the key reasons the company was formed, and their products developed, was to reduce the incidence Necrotizing Enterocolitis. The company’s reason for existing is the prevention of NEC. And the research presented to us by Dr. Lee was stunning. So when we began producing this series, it was only fitting to invite Dr. Lee to share the benefits of an exclusive human milk diet to premature infants and the clinical research supporting its use. With that in mind, let me introduce my guest today. This is Dr. Martin Lee from Prolacta Bioscience. And I’m so glad you could be with me here today. How are you? MARTIN LEE, GUEST: Good. How are you doing Stephanie? STEPHANIE: Good, good. So in previous podcasts, we’ve talked to doctors that are attending neonatologists and researchers. So I would like to give you the opportunity to give a little bit of your background and how you got involved with research in NEC. DR. LEE: OK. Absolutely. Well, I spent probably most of my career doing clinical research with various types of pharmaceutical and biotech products. I started with a company you’ve probably heard of called Baxter approximately 35 years ago, and I spent a good number of years working with them. And how that’s relevant to our discussion today is I was working with their group that manufactures blood products, and obviously blood is a significant human fluid, has many of the same issues with regards to safety that we have with breast milk. And so I learned a lot about some of the testing that needs to be done, some of the safety factors that we need to consider. And then I would say about 15 years ago, I met someone who was talking about forming a company who basically wanted to bring breast milk and breast milk products to premature infants so that they would have the benefit of receiving 100% human milk diet, particularly the smallest of the small premature infants. So together we started the company Prolacta. And the whole idea of course in starting the company was to put it‚…I think the most important thing was to put it on a firm clinical scientific basis. And that meant doing really important well-designed clinical trials to evaluate the most important morbidities like NEC, in particular, and even mortality in premature infants, infants certainly that had a high risk of both of those consequences of prematurity. STEPHANIE: OK. Maybe not all of the people that will be listening fully understand…what is an exclusively human milk-based diet? Can you get into that a little bit? DR. LEE: Absolutely. So obviously we know‚…we meaning pretty much the world understands that the best thing a newborn baby can be fed is mother’s milk. And for term babies, that is obviously going to be sufficient. They’re born at the right time and usually at a sufficient weight and mother’s milk has all the good things in it that help the baby to grow, help their immune system to develop, help their organs to develop, importantly it helps their brain to grow at the right rate. But a premature baby by definition is born too soon. And we specialize‚…the work that we’ve done at Prolacta,…specializes in the infants that are born as much as 27 weeks or 12 weeks premature so 27 weeks since the time of gestation. When those babies are born, they have a lot of problems obviously because they’ve come out of the womb way too early. And one of the things that of course they are is way too small. The average baby that we’ve studied in our research trials is less than a thousand grams. That’s around two pounds. Now most people know that the average baby is 6-7-8 pounds. And so they’re born so small that what happens is that mother’s milk which of course comes in when the baby’s born‚…nature didn’t intend mother’s milk to be able to feed these type of babies. This is an unfortunate consequence of something that happened with the mother, something that‚…injury, genetics, whatever it is that would cause a baby to be born premature, the milk comes in, but it cannot feed that baby well enough. And what I mean by that is the baby needs to grow. He needs to grow a lot. The baby needs to have their immune system protected by the mom’s milk, and so on and so forth. So obviously we always talk about mother’s milk being the thing for a newborn baby. It’s not enough for these premature infants. So what they need is what we call a fortifier, something with a little extra kick to the baby. And there are fortifiers that have been on the market for a long time. They’re made by the formula companies. And naturally these fortifiers are made from cow’s milk. And cow’s milk is not the best thing for a premature infant. It may not be the best thing for babies in general, but besides the point, it’s certainly not the best thing for a premature infant. So when we’re talking about 100% or exclusive human milk diet, we’re talking about mom’s milk; we’re talking about a fortifier which is necessary for the baby to grow and to be protected from infection and so on and so forth. That comes from human milk. And what Prolacta did was develop the world’s first human-milk human milk fortifier. And in fact, it sounds like a mouthful because when we talk about human milk fortifier, general people realize or may not realize that that’s a cow’s milk-based fortifier. We make the one from human milk. So that’s what we mean by 100% diet. And then one other thing just to add to that, Stephanie, is sometimes mom’s milk doesn’t come in enough or the baby wants it or needs to eat more, get more milk, so then there’s donor milk involved too. And that’s another aspect of the 100% diet. And of course donor milk is coming from other moms, which again provides the additional nutrition that the baby needs. And there you have the entire spectrum of what we mean by 100% human milk diet. STEPHANIE: OK. Thank you. Yeah, I know that there’s probably a bit of confusion amongst parents new to the NICU that human milk fortifier is a fortifier put into human milk, and not necessarily made with human milk. So I know that that does tend to cause a little confusion. DR. LEE: Right. STEPHANIE: So thank you for clarifying that. DR. LEE: Sure. STEPHANIE: So I guess I’ll ask you to go into a little bit of the research because I find it fascinating. As you know, we were out to your facility in November and I thought that this is a fabulous company. I was not aware of it when our babies were in the NICU and I will just make a tiny note that I know you’ve got significant statistics showing the benefit of human milk and exclusive human milk. Unfortunately for Morgan, he fell in to that other small percentage that I did pump. But he developed NEC so rapidly at four days old being born at 28 weeks. At four days old he developed NEC and I don’t think he had two feedings. So there are babies that get it even when all attempts are made to have an exclusive human milk diet. DR. LEE: Sure. STEPHANIE: And I also know that my other son, Shaymus, his milk was fortified, and to be honest, I’m sure it probably wasn’t with an exclusive human milk fortifier. So just some things to sort of give everyone background. And again, that was, you know, four years ago, 2010-2011. DR. LEE: Sure. I hope…I assume they’re doing OK today, right? STEPHANIE: Yes, yes. Everybody’s doing very well today… DR. LEE: Excellent. Excellent. STEPHANIE: which I think is why I’m so personally‚…my personal opinion is that your products are wonderful and, you know, things being what they were then versus now, I would definitely advocate for 100% human milk diet and advocate for this if I was a parent in the NICU now. So I think it’s great to get this information out to people. DR. LEE: Sure. Absolutely. So your question concerned the type of studies we did. Well, as I said to begin our conversation, we recognized that the only way that people‚…the medical community, both neonatologists, nurses, lactation people‚…would appreciate and realize the importance of what 100% human milk diet does and helps as far as the baby is concerned is to do proper research. As I said earlier, my experience is in the pharmaceutical and biotech industries where doing formal randomized controlled all the kinds of bells and whistles that need to be done when you need to license a drug or a biologic for marketing in this country and other places in the world as well. That’s standard stuff. So when we set out to do these studies, we said what we’re doing here is just as important, just as the need for rigor has to be here as it would be in any other kind of situation where you’re testing a new medical intervention. And that’s what this is. So we decided right off the bat we would get together the best of the best as far as the neonatologists in this country are concerned, and we brought them together and we set up a protocol. And basically the protocol was based on a very simple premise. It is 100% human milk diet better than feeding a baby mom’s milk fortifying then with standard human milk fortifier and then if all else fails or at least maybe not be sufficient than using formula. That’s standard practice for premature infants in this country. It was in 2007 when we started this trial and to a large extent it still is today. So it’s 100% human milk diet standard of care which includes cow’s milk based fortifier and formula. Babies in this study were randomized which is‚…you know, it’s a fairly simple term, but just to make sure everybody understands what I mean by that, the decision when a parent agreed to have their baby be participating in the study which group they get into, the Prolacta or the 100% diet versus standard of care was essentially a coin flip, not literally of course, but that’s the basis. Now why do you do that? Because that’s the best way to design studies. It provides an unbiased approach to making the decision of treatment of nutritional treatment, taking it out of the hands of anybody and putting it in the hands of strictly chance. So you randomize babies. There was a sufficient number of babies in the first study we did. There was over 200 babies that were randomized and I think it was 12 centers around the country. And what we were looking for in this study was whether or not they develop NEC and that was the most significant endpoint of the study. There were other things that we looked at. We looked at how much parenteral nutrition they received. We looked at other things. We looked at sepsis. We looked at‚…which is essentially bacterial infection that circulates in the bloodstream. We looked at hospital days. We looked at days on a respirator/ventilator and so on and so forth. But the main endpoint in this study was Necrotizing Enterocolitis. Now, the babies, by the way, that we used in this study or the babies that constituted the population of the study were babies under 1250 grams (2 pounds 12 ounces) down to 500 grams (1 pound 1 ounce). Very simple reason for that. I think many of the people listening will know that there’s a classification of premature infancy called very low birth weight. And that’s babies under 1500 grams (3 pounds 4.91 ounces). But we said, you know, we want to get the babies that have the highest risk of NEC. So we didn’t use, if you will, the heaviest babies in that weight category because they have, it turns out, the lowest risk of NEC out of all very low birth weight babies. So we took away that 1250-gram group. We also didn’t go below 500 grams because unfortunately, babies born less than 500 grams which is really about a pound or less have unfortunately not a high chance of either succeeding in life really and survival or they have a lot of other problems that make it very difficult to evaluate then. So it was 500 to 1250. That’s basically, I think, the most important aspect. And like I said, they were randomized. We followed them for a period of 90 days, maximum 90 days. Babies could have gotten off the study earlier if they got on to mostly oral nutrition which of course hopefully babies all do because they start off with what’s called parenteral nutrition which means they get their feed essentially through intravenous feeding. They then transition off of that onto enteral feeding which is typically a tube that goes either through their nose or directly through their mouth into their stomach. And that’s called enteral feeding. And then they go to oral feeding. So babies who are on for 90 days or if they got to oral feeding sooner, then they were off the study. Very simply, just to summarize what constitutes a fairly complex study to manage, we found a magnificent reduction in Necrotizing Enterocolitis. The babies in the standard of care group had a NEC rate of about 16%. Or put simply, that one in every six babies develop NEC that got some sort of cow’s milk protein or cow’s milk diet. The babies who got 100% diet was less than 6%. That 16 to 6 is about 70% reduction, and that is phenomenal. We’ve had some of the really very famous neonatologists told us that they don’t see‚…you don’t see that kind of reduction with really any intervention that they’re used to seeing. You just don’t see that. You see incremental things. But now all of a sudden we cut NEC by 70% by doing this. And it even gets more impressive when you consider that the majority of babies or at least half the babies who develop NEC have to go on to have surgery. STEPHANIE: Right. DR. LEE: And that is a really serious consequence not only just from the fact that a premature infant has to go on to major surgery and they take out part of their digestive tract. But even worse, they have a reasonably high mortality rate. So in this study, the rate of NEC surgery of all those babies that were in the two groups, it was at 11% in the standard of care arm and only just over 1% in the Prolacta arm. We reduced the rate of NEC surgery by eight fold, I mean just an incredible difference. Virtually wiped out NEC surgery in this study. STEPHANIE: That’s amazing. DR. LEE: Yeah. I mean, we expected to see something really good. We didn’t expect‚…I guess you could say well we should have expected‚…but it was beyond our expectations, wildest dreams to show this kind of effect. Now a lot of people have looked at this data and said well that’s interesting, and maybe that’s real. But can you‚…you know, can you do it again? And the answer is yeah. We did it again because that first study that I just described, these were only babies who were getting‚… which are most babies‚… who were getting some breast milk from their mom. But there are a small cohort of‚… I don’t know quite what the percentage is in this country, but there’s a percentage of babies who don’t get any breast milk. There’s various reasons. Mom is sick. Mom’s not available. So on and so forth. So we also did a second study in which we only treated babies or fed babies who had to get their nutrition either one of two ways. Since breast milk wasn’t available, they got formula. Soon as they were able to get enteral feeding, in other words the tube feeding, they got formula. That’s one group. The 100% arm, same thing, except here, instead of getting mom’s milk, they got donor milk, and then they got the fortified. So it was a real stark comparison. Only human milk, only formula. And it was a very small study. It was only‚…that first study, I don’t know if I mentioned or made clear, that was a 200-baby study. Pretty big study. STEPHANIE: Yes. Um-hmm. DR LEE: This study was only 53 babies partly because it was very, very hard to find these babies. I mean, we would sign up a mom, they would agree to put their baby on, and then they realized gee, I really want to feed my baby. I really want to give them breast milk. And of course, that’s fine. That’s great. STEPHANIE: Right, right. DR LEE: But they can’t participate in the study. STEPHANIE: Right. DR LEE: So we had a hard time finding. But we eventually did it. Took us three years to find 53 babies, but we did, and you know what? We found the same significant difference, particularly in the surgical NEC. There were‚…in the control arm, there were 24 babies, and four of them had to go on to surgery for NEC. That’s one in six. So about 16%. In the Prolacta arm, in the 100% milk arm, nothing, no surgeries, nothing. One case in NEC overall, but no surgery. So that turned out to be wow. That’s the kicker. Two separate studies, two different classes of babies, breast milk, no breast milk, doesn’t matter. When you give a baby that’s born premature like this, this weight category, less than 1250 grams, and you feed them with only human milk, they’re going to do better. And it even turns out when you start putting all the data together an extra‚…I hate to call it a bonus‚…but an extra important key outcome was that mortality was reduced. Mortality fortunately in this baby population is pretty low. It’s about 8% overall because of the prematurity, of course. We reduced that to 2%. So a four-fold reduction in mortality. So now when you put it all together, what do you have? You have prevention of the major morbidity‚…that is NEC‚…of prematurity, and you prevent mortality. And how can you really ask for anything more from a nutritional approach to these really fragile infants. STEPHANIE: Right. Right. No, I totally agree. And as I said before, my personal opinion, you know, as the mother of a surgical NEC survivor, I would advocate for this if we had to do it again. It’s definitely phenomenal. DR. LEE: Yeah, it’s almost this kind of effect you would expect to see if this was a pharmaceutical breakthrough or some new wonder drug or some sort of biotechnologically-produced intervention. But all it is is feeding the babies properly. I mean it’s such a fundamentally sound, logical‚…this is what nature wanted these babies to get. STEPHANIE: Right, right. DR. LEE: Babies should get human milk, nothing else. STEPHANIE: Now you had mentioned previously the difference between donor milk and then your human milk nutritional products. Can you‚…when I hear conversations, I sort of always think it’s like comparing apples and oranges. You know, it’s almost two different things. So can you clarify what the difference is with donor milk and your products? DR. LEE: Well, again, I’m sorry to be maybe not entirely clear. We make a donor milk product. Essentially, all our products are made from donor milk, both the fortifier, of course, and we make a simple donor milk product that is formulated to have 20 calories per ounce which is what doctors and nurses and dieticians believe they’re giving the baby when they feed the baby either mom’s milk or milk from another person. So donor milk is essentially the equivalent of mom’s milk other than the fact, of course, it comes from another mom. But however‚…and in fact, the American Academy of Pediatrics has said the best thing for a baby is mom’s milk. But if mom’s milk is not available, then donor milk is good. STEPHANIE: Right. DR. LEE: But the problem, of course, and one of the I guess you could say‚…I’m trying to think of the right word. Bad things that people associate with donor milk is well it comes from somebody else, and how do I know that person is the right person to provide milk for my baby? And that’s one of the key things that we had at the center of what we did at Prolacta from the beginning, which was to have a safety profile that was beyond reproach. I mean, we do things as far as testing the moms, testing the milk, that nobody else who ever handles breast milk does pure and simple. I’ll give you some examples. One of the things that I thought of very early on is because, again, remember I told you I came from the blood industry and they test blood and they test donors obviously every which way you can think of. But there’s one additional problem that donors who provide milk have in a sense that blood donors don’t. When you take blood from a donor, you’re seeing the person and it’s blood coming out of their vein and it’s coming right into a bag and you know whose it is. But a milk donor, she donates at home, pumps at home, puts it into containers, and then sends it wherever the donor, the milk bank, might be. In our case, it’s here at Prolacta. They’ll send it to us, and here’s the problem. How do we know it’s that person’s milk? STEPHANIE: Right. DR. LEE: How do we know it’s the person who we screened and did all the blood testing on to start with, that it’s her milk. So we do something very, very unique. We actually have the mom provide a DNA sample, they do a little cheek swab, they put a little stick essentially in there, and scrape off a little tissue from inside their cheek, send it to us so we have a profile. Now she sends us her milk, and when she sends us her milk, we can actually match it up. And now we know it’s that safe mom’s milk, all right? Now you might ask what’s the point? I mean what self-respecting individual is going to send somebody else’s milk to you? And the answer is nobody, for the most part I can say almost universally, will do that intentionally. But there are mistakes. I mean one of the things we’ve seen is moms that are lactating, sometimes there’s a couple of women in a neighborhood, and they’re all doing the same thing. And somebody’s freezer will become full with milk, and they’ll say to their neighbor, “Can I put my milk in your freezer?” And they said, “Sure, no problem.” And she’s got her own milk in there. And then they go to ship milk and lo and behold, there’s somebody else’s in there. We love that‚…we love the moms, but we have to be sure that every mom that donates is a mom that’s free of all of the nasty things that could be in blood because those things could be in milk as well like AIDS and hepatitis and syphilis and all those kinds of things that we should be concerned about. Even as an adult you certainly want to get blood from someone like that. You certainly don’t want to give that to this fragile premature infant. STEPHANIE: Right, right. DR. LEE: So going back to your original question about what we do versus donor milk, that’s all one in the same, I think you could safely say. Everything is based on the concept of donors and the milk that they provide and the safety of that milk supply being tested from any way you can think of so that every product that’s made from human milk is as safe as possible based on all of the different protocols that are used. And that includes other things besides DNA testing. It includes drug testing; it includes testing for whether the mom smokes because they may tell you they don’t smoke, but we’ve seen that instance where there’s byproducts of nicotine in the milk, and that’s not good for a baby. So we do that kind of testing. It’s just a laundry list of things to make that as safe as possible. STEPHANIE: Right. And I guess‚…I’m sorry‚…I guess to clarify my original question, I was speaking specifically about your fortifiers versus human milk. If you could explain a little bit the difference of that‚…I mean this was a very good‚…I can’t think of the word‚…a very good deviation, but yeah. When I was saying apples and oranges, I meant donor milk versus fortifier. DR. LEE: OK. I’m sorry. STEPHANIE: No, that’s OK. DR. LEE: The fortifier essentially‚…if you want to keep it very simple, the fortifier is just very concentrated milk. STEPHANIE: OK. DR. LEE: So essentially, what you do to make the fortifier is you take milk, you filter it to get rid of a lot of the fluid so that you concentrate the protein, you concentrate some of the other important nutrients in there. And that way the baby can get extra, like we say, protein, extra other nutrients in a very, very small volume. So for example, in our typical fortifier which we call Prolact +4, if you add that to mother’s milk in a ratio 80% mother’s milk to 20% fortifier, assuming mother’s milk is about 20 calories per ounce, you’re going to add 4 additional calories for that baby in that small volume which is a lot. So then we can actually do even more than that. We can do a +6, six calories, we can do +8 and even +10. That kind of product is for the babies that are the most fluid restricted. They can get 30 calories per ounce in the same volume that milk that originally was 20 calories per ounce was. So that’s really important for those babies, for example, that have heart defects who can’t take in a lot of fluid or babies for whatever reason are fluid restricted. STEPHANIE: OK. Thank you. DR. LEE: Sure. STEPHANIE: Yeah, that was‚… I think it’s important for parents and family members that might be in the NICU to be able to have a conversation with their doctor and fully understand what’s being given to their baby and be able to ask the right questions. So would there be anything else that you would want to add if you were talking to a parent who’s got a baby in the NICU right now for them to be able to advocate best practices for their baby? DR. LEE: I think that the simple issue for a parent under these circumstances is to ask the doctor based on all of the evidence that’s out there, clinical evidence,…and that’s how doctors make decisions. We talk about evidence-based medicine. This is based on the best evidence that the doctor is aware of, what’s the best way to feed my baby? And having said that, you know, the evidence that we’ve discussed here today is for those smallest of the small. For a larger baby, this is not necessarily‚…it’s not that it’s wrong. It may not be necessary, but when you’re dealing with the smallest babies and the ones that are struggling to survive and grow and thrive and get to where you want all babies to get to, to childhood and so on, then you have to ask the doctor the question what is the best way that our baby can get out of that NICU, that Neonatal Intensive Care Unit, and get home and be with his or her parents. That’s really, I think, the fundamental question. And the doctors should be able to answer that question based on the evidence that exists for the diet that the baby should be fed. STEPHANIE: Right. Thank you. Yeah, I think this is a really great conversation for any parent in the NICU, especially those, like you said, the smallest that are at the highest risk for developing NEC and as you said, other issues as well. And it’s‚…it can only be a benefit in my opinion. DR. LEE: Absolutely. And just to add to that, they should also ask the question‚…because there are other sources of nutrition, and there are other places from which milk can be attained we know about, for instance, women sharing milk on the Internet, milk sharing sites. You’ve got to be extremely careful. You’ve got to ask the question not only what’s best for my baby from the point of view of effectiveness, but also what’s the safest for my baby. And you want to be sure that the source, where that milk is coming from, where those products are coming from, comes from a place where you can say everything possible based on modern technology has been done to protect that milk, protect the safety of that milk. And I think that’s really critical. I think there was a story the other day‚…I forget which show, where it came up in one newspaper or another‚…about‚…oh, I know what it was. It was an article that was published that basically looked at milk samples. They actually collected milk on one of these sharing sites, and they found a large percentage of them had nicotine in the milk, had other things, other bad things that you don’t want a baby to have in that milk. So you’ve really got to ask that question what’s the best? What’s the safest for my baby as well? STEPHANIE: Right. Right. And Prolacta has provided us some material, some reference materials for sharing. So I will say that we’re going to be posting those on our website and will have them in the show notes as well. And I really appreciate you taking the time to talk to me today. If there’s anything else at all that you would like to add, please feel free. DR. LEE: Well, I just want to thank you for the opportunity to let obviously the parents out there know that we’re here for one very, very simple reason. I mean I know it may sound kind of corny, but we said from the day we opened the doors at Prolacta that we’re here to save babies, and I think we’ve done our job in that regard. And we’ve proven that that’s the case. So I’m really‚…I’ve worked, as you heard me say, for 35 years doing clinical and medical research, and I’m very, very proud to say that this is, I think, my best story to tell out of all that long career. STEPHANIE: Right. And as I said, I was out in the facility, took the tour in November, and we were very impressed with your company. And like I said, if I had to do it all over again, I would certainly be asking these questions and in my opinion, I think this is a phenomenal company. And your rigor in testing and your facility are top notch. So thank you. LEE: Well, thank you. Thank you. I really appreciate that, and it means an awful lot to me and to obviously everybody that works at Prolacta. STEPHANIE: Right. So thank you for joining us. And hopefully we’ll talk again soon. LEE: Alright. Thanks so much, Steph. STEPHANIE: In closing, I’d like to share a few thoughts about today’s conversation with Dr. Lee. Recently, I’ve seen a lot written about the use of donor milk, human milk products, and the emerging breast milk industry. Often times, the opinions expressed about Prolacta are solely related to cost: the expensive of Prolacta’s products versus those coming from nonprofit donor milk banks. In my opinion, the cost of using Prolacta’s human milk-based human milk fortifier far outweighs the potential risks of not using it, and any discussion about cost needs to be framed within the context of total cost of care. As Dr. Lee mentioned, Prolacta’s human milk-based nutritional products are intended for extremely premature infants who weigh less than 1250 grams (2 pounds 12 ounces) at birth. My son Morgan weighed 2 pounds 5.5 ounces at birth; my son Shaymus weighed 2 pounds 7 ounces. Prolacta openly shares that the typical cost of using their human milk-based human milk fortifier for these babies is $10,000. That, however, is only a fraction of Morgan’s and Shaymus’ total cost of care. Each of whose exceeded $1 million. In actual numbers, the cost of an exclusive human milk diet using Prolacta’s human milk-based human milk fortifier would have been less than one percent of Morgan’s total cost of care, and less than one percent of Shaymus’ total cost of care. And while Morgan’s case shows that no current preventative strategy for NEC is 100% effective, research shows that access to, and the use of, an exclusive human milk diet significantly reduces the risk of NEC in the majority of extremely premature infants. Show your support for our smallest and most fragile babies, those who have the greatest risk for developing NEC. Show your support for continued research in NEC. And join our effort to raise awareness about, and funds for research in NEC by making a donation to Morgan’s Fund at morgansfund.org. If you’ve had a personal experience with NEC and would like to share your story, or have a question or topic that you’d like to hear addressed on our show, e-mail us at feedback@morgansfund.org. We’d love to hear from you! Additional resources: Prolacta Bioscience, Inc. What Is Necrotizing Enterocolitis? N.p.: Prolacta Bioscience, 2015. Print. Prolacta Bioscience, Inc. 100% Human Milk: The Best Nutrition. N.p.: Prolacta Bioscience, 2014. Print. Prolacta Bioscience, Inc. Nutrition for Premature Babies. N.p.: Prolacta Bioscience, 2014. Print. Prolacta Bioscience. Premature Babies: What to Expect. N.p.: Prolacta Bioscience, 2014. Print. Copyright © 2015 The Morgan Leary Vaughan Fund, Inc. The opinions expressed in Speaking of NEC: Necrotizing Enterocolitis (the Podcast series) and by The Morgan Leary Vaughan Fund are published for educational and informational purposes only, and are not intended as a diagnosis, treatment or as a substitute for professional medical advice, diagnosis and treatment. Please consult a local physician or other health care professional for your specific health care and/or medical needs or concerns. The Podcast series does not endorse or recommend any commercial products, medical treatments, pharmaceuticals, brand names, processes, or services, or the use of any trade, firm, or corporation name is for the information and education of the viewing public, and the mention of any of the above on the Site does not constitute an endorsement, recommendation, or favoring by The Morgan Leary Vaughan Fund.

Audio File:  Download MP3Transcript: An Interview with Stephanie Boyle Founder, Rogue Paper, Inc. Date: August 29, 2011 [music] Lucy Sanders: Hi, this is Lucy Sanders. I'm the CEO of NCWIT, the National Center for Women in Information Technology. We're working hard to make sure that more girls and women are introduced to the exciting potential of computing education and career paths. Part of what we're doing is this exciting interview series with women who have started IT companies. They're fabulous entrepreneurs. They all have such interesting stories to tell. today we're going to interview another one, Stephanie Boyle. With me is Larry Nelson from W3W3.com. Hi, Larry. Larry Nelson: Oh, it's really a pleasure to be here. We like to focus, of course, on business and high technology with a special emphasis on young girls and women in technology. NCWIT has been doing a marvelous job. We're happy to be a part of it. Lucy: Well, and thank you very much for all the support that you give us with this excellent interview series. Now let me say a few words about Stephanie Boyle, the person we're talking to today. She's nothing less than a pioneer in the mobile Internet space as far as I'm concerned, having first helped shape the area as a founding member of Ericsson's Digital Media Innovation Center. Big brain thinking going on in this center, and it really helped to shape the whole mobile area. Now she is the founder of Rogue Paper, and she and her team deliver integrated mobile experiences to users. Now in the old days we used to call this convergence, but there's really a whole lot more exciting language and capability around the space today. I'm sure that Stephanie will be talking about that. But some of the things you can do now with the things that they're working on with Rogue Paper around co‑viewing a TV show and interacting with social media at the same time and integrating all of that. You're thinking, "That's really cool real‑time experience." But wait. There's more. You can actually do it with a rerun, where you can experience the whole power of what people said about the show or whatever movie and do it even when you are replaying or rerunning it. Just really interesting types of interactions going on right now and certainly leading to more engaging experience for viewers. Stephanie, wow! You've got a great company. Tell us a little bit about what's going on here. Stephanie Boyle: Thank you. Rogue Paper, we really started the business a year and a half ago with the mission of using mobile applications and technology to help enhance and drive traditional medium broadcast. Basically we are self‑proclaimed "TV‑holics"... Lucy: [laughs] Stephanie: ...and recognized [laughs] that we really wanted to not only watch television but really interact with the social sphere while we're watching these shows, that the content goes beyond just the primary screen. Really there is a second screen opportunity that can be interactive and augment the primary screen. There's a lot of really bad television being watched, but then [laughs] along with a lot of our guilty pleasures, which makes our jobs definitely a little bit more fun. But we really focused on how can we make the primary screen of television an interactive experience for users on the second screen, whether the second screen is a mobile device, a tablet, a desktop experience, or other things? We're trying to provide the users with second screen interactive content but then also provide media companies a way to reach these people already multitasking, who are already texting with their friends or IM‑ing or posting to Facebook or tweeting about what they're watching. It's really trying to bring the experience together as one single destination for a viewer and for the media companies to really have a holistic double‑screen experience. Lucy: That's really phenomenal. OK, I have a lot of guilty pleasures with TV, too. [laughs] One of them is American Idol, right? Stephanie: Right. [laughs] Lucy: When people are performing, and then people are tweeting or they've got things to say later in the blogs, and it's just not as much fun as if you could see it right then. Stephanie: Yeah. Well, and if you think about it, television has always been a social experience. It started in the 1950s. Maybe one or two people on a block had a television. It was really event driven. The people would come and sit together, and watch whatever was on the television and really talk about it together. Then as the technology innovations and as even socio‑economic things happened, we had VCRs and all of these second screens in the home, second televisions in the home, if you go into the seventies and eighties. Then the conversations started moving around the water cooler, so it was where people aggregated. It could be eight hours, 10 hours, 24 hours after the show aired. In the last two decades this has really moved into a digital landscape. I would say in the last five years or so it's really become back to real time because people aren't sitting together anymore. They're actually on their sofas or tweeting or talking, texting, or instant messaging. All these different mediums, but it's all really because, as a medium, it is social. Lucy: Yes, it certainly is. I remember the first time I saw a color TV in my neighborhood. It was Halloween. Larry: Oh! Lucy: I know. Stephanie: [laughs] Lucy: I was trick or treating. Anyway, back to you, Stephanie. Why don't you tell our listeners a little bit about how you first got into technology? Stephanie: Yeah. I was always interested in systems and the way things interconnect. I was of a generation that there was one computer in our elementary school to having them in high school and later. But wasn't necessarily as intrigued with the computers themselves as I was with the Ataris, the ColecoVisions, [laughs] the computer systems that we had at home that really could help me build games or play games. But always interested in how the systems worked and how people interacted with them. Actually, my mother was the first person to show me a computer in a way where she took it apart and had me put it back together. Lucy: Oh, that is awesome. Stephanie: Yeah. [laughs] While I'm not a digital native, I was exposed to technology as something that could be deconstructed to learn about and then put it back together. It definitely eliminated fear for me. It's always something that I felt was accessible, interesting, and intriguing. As time went on, I'm self‑taught in a lot of ways because of that because if I don't know how to program in HTML5, I'll have somebody [laughs] do it for me. Then I'll take it apart and try and change it and put it back together. But definitely I look to my mother as the person who eliminated that "technology is this strange and new" thing and made it instead something that was tangible and interesting. Larry: I wish I had known you a number of years ago when we needed something put back together. [laughter] Stephanie: Right. I remember being intrigued by this whole concept of my mother showing me the mother board in the computer. [laughter] Lucy: That's great. Stephanie: [laughs] I didn't really believe her that that was what it was called. Larry: Being the father of five I thought it should have been called a father board. But anyhow... Stephanie: [laughs] Larry: You've been through a great deal. You're really building an interesting company. What is it about entrepreneurship that makes you tick, and why did you become an entrepreneur? Stephanie: Well, it's really interesting. I think the most exciting part of being an entrepreneur is the infinite blank canvas. Even when you have a product, an idea, a customer, anything, the next steps are never really clearly defined. Persistent problem‑solving and adjusting can be exhausting, but overall for me it's invigorating. It's how do we get to the next step? How do we keep moving forward? What ways do we need to be nimble and still meet our business objectives, our product objectives, our client objectives, the user objectives? It almost feels like the future is so undefined, and in that way I feel like it's really exciting. I often liken it to building a bridge while you're walking over it, which, of course, scares our business people to death. You should build a bridge on a [laughs] stable foundation. But what I mean by that is being an entrepreneur often allows you to be nimble enough to defy gratify and space as necessary. You're moving forward, but the future is undefined and you are still defining it. Lucy: Well, you're inventing it. I mean entrepreneurs are great inventors, right? Stephanie: Yeah, definitely. It's so exciting. Right now we share an office with actually four other startups. The collective energy is so interesting, just watching teams work together and just the steam coming off [laughs] the teams. It's exciting, and some of the things they talk about doing I think are impossible. I'm amazed at how those can be executed. Lucy: Well, now Stephanie, you mentioned your mother as having influenced you, really built your confidence, took the fear out of approaching technology and understanding it. Who else has influenced or supported you on your entrepreneurial career path? Stephanie: There are so many. I wish I had time to name them all. I can tell you the very first person who helped me grow as an employee or an executive or as a contributor to a team was by boss at Ericsson. Her name was Donna Campbell. She's a founder of Ericsson Cyberlab that was Ericsson's Digital Innovation Center. Donna had a very good and healthy way of looking at growth. We have a job that we have to do to make the trains run on time every day, but beyond that take time to learn more about this exciting new area that was mobile Internet or this new thing that has been so undefined because Telco previous to that the only content that existed was voice conversation, that people were talking to each other. It was just a voice channel. Then we were really looking at this next generation, which included data applications, content, anything. While we had all of our jobs to, what we would say, make the trains run on time, whatever that job was, she really challenged us to always think about learning about this new space and helping to define it. I sometimes even just with our team or our employees, I think I hear her voice in my head encouraging them to be as creative and also forward‑thinking and less constrained, that all ideas are really good ideas. Larry: I'm curious. With all the things you've done so far, not only with Ericsson but now with this newer type startup, what's the toughest thing that you've had to do in your career? Stephanie: [laughs] To be perfectly honest, it's probably less about my career itself and more about my personality. But I really believe that the toughest thing was really to learn to listen. That is in a big organization. That's with your own staff, employees, and partners, with your customers, with anything. I mean it's very easy to believe that you know what is the right way and to feel confident in your decisions and to try and push those things forward if you have a little bit of a bulldog personality, which I have. Still, I think the hardest thing for me to do is to really take a step back and realize that not only are all opinions really interesting and can spark new ideas for a collective group, but that you have to pay attention to what people are saying, and really listen. While that shouldn't be a tough thing in a career path, I think it adds growth as a human being, and applying that to my career. It's something I also believe that Donna really taught me, was that while maybe in the end your way is the right way, there are five, ten other people who can contribute and make it a better thing. Larry: Stephanie, we love your candor. Lucy: I have to say that this is such an important point. I can remember when I worked at Bell Labs that we took some amount of our imagination from "Rolling Stone Magazine." Who would figure? Stephanie: Right. Very cool. Lucy: Yeah. Around what we were doing with multimedia communication interfaces, and it came through this person who was sitting on the beach one day reading "Rolling Stone" on vacation. He brought the idea back to us at the Labs, and we at first didn't listen to him. Then we read the article. [laughter] Stephanie: It's interesting when you're really thinking about working through multimedia and technology, it's very easy as technologists to come from, "Well, this is the way it should work." It's really hard to think about, these are the other people on the value team, the people who create music. When you're thinking about all pieces of the value chain, it's really easy to focus on the technology. It's hard sometimes to remember that not only are, maybe, music companies involved, or people who listen, or all the other pieces along the way, to really bring them together. It's sometimes hard to get out of the tasks that we're doing today and think about the holistic view of the ecosystem. Lucy: I'll tell one other quick little story. At Bell Labs, in my organization, we finally realized that the Internet was real when a woman appeared on "The Donahue Show." Remember "The Donahue Show?" Stephanie: Yes. Lucy: OK. The sensation, of course, much more plain than it is today on some of those shows, but the sensation was that she was getting divorced because she had been talking with some other man on the Internet. They did a whole show. [laughter] Lucy: Stephanie, if you were sitting here with a young person and giving them advice about entrepreneurship, what advice would you give them? Stephanie: I actually think that the best advice I could give to anybody would be to take time to learn, to go and do internships, to find the salty dog in the organization who isn't always the oldest person in the organization, or the person who might be a little contrarian. Find those people and really learn about how you can work with them and how you can support them in all of their issues. I think internship is so important. I think coming to an organization with ideas is amazing. I think learning to collaborate and gain consensus amongst a huge number of people who are key influencers within the organizations are really, really good ways to learn how to contribute. I think becoming an intern in a larger organization, or even a smaller organization, and then making sure you touch all points of that organization, gives you a view of how an entrepreneur has to live. Some days I write business cases. Some days I do contracts. Some days I deal with end users. Some days I deal with angry clients on our side. Some days I'm troubleshooting why the applications have bugs in them. Really taking time to learn all of the aspects, all of the people in an organization, helps later to learn what it's like to be this utility person, which is all entrepreneurs. Some days you're accounting and some days you're dev, and all places in between. I think the best exposure is either (A) working in a big company where you intern, or working side by side with other entrepreneurs who pick up the six different hats a day, or even in an hour. Larry: I know a coming out of Ericsson and all, and that was great experience, but what is it about you personally that gives you the advantage of being an entrepreneur? Stephanie: I think I mentioned this a little bit earlier, but I am a little bit of a bulldog. I think when people say that people are like their dogs, I have a very, very, very adorable and stubborn French bulldog named Weesie. I think we share some characteristics, in that when we I want to do something, or think that it's something that is good for the company, or for end users, or for the organization, I can't let it go until we get there. Whether we have to take five different routes to get to the same place, I really think that having a vision and sticking to it, but not sticking to how you get there, is really important in being an entrepreneur. To be flexible and learn how you can do it differently, or any of those things is really important, but just owning what you want to do and, hopefully, the outcome is really important. I think as a characteristic, and while I don't necessarily want to be considered a puppy with a sock. I am sometimes gnawing on that sock until we really can get to the vision. We're flexible enough to think that the vision can change over time and evolve. Definitely, especially within Rogue Paper, because this is a business we wanted to build, to make TV exciting for viewers, but then also just to help media companies to engage with their users and also to drive their core business, which is broadcast advertising. Really thinking about how to keep bringing eyeballs back for them. We'd done a few things to get it to change as time goes on. But I think definitely we always stick to this vision that we really think mobile can help drive traditional media. Lucy: I think it's great advice to think about sticking to your vision and being flexible with the way you get there. That's a powerful piece of advice. Changing gears just a bit, you're very busy, obviously. You're working hard on your company. I'm sure you have a wonderful set of friends and family around you as well. Larry: And a bulldog. Lucy: And a bulldog. [laughter] Lucy: How do you bring balance into your personal and professional life? Stephanie: It is very difficult. It's one of the bigger challenges, I would say, that most entrepreneurs have. I think the most successful are those to whom work is play, to some degree. If you love what you do and it bleeds into your personal life, it's not necessarily a hassle to do that. It's still that you're so excited about what you're doing and you're consistently thinking about it. In that way, there is not a huge difference in work life in terms of happiness. It's exciting to work at work, it's exciting to think about it afterwards. But it's interesting. Every company has growth phases. There's an innovation phase. You go through these big bursts of time when the focus gets really hard. I have an agreement with people in my personal life that in those two or three months, or in this growth phase, that I might be checked out a little bit. Then after that period goes, or after we solve a big problem, then I'm back at the dinner table and being an active participant in life. I would say it's not a burden on me, but it can be lonely for the other people in your life. Fortunately, the bulldog doesn't really notice as long as you throw the ball. [laughter] Stephanie: But it is a challenge. It's something that I watch people do around me. My business partner and co‑founder, she works nine hours a day full time, really hard during those times. Then she's able to really turn it off afterwards. It's something that impresses me and I admire, but at the same time, my brain is going at all times. I don't necessarily turn it off as well, or go as intensely during the day, but it is definitely one of the bigger challenges. But I would say in partnership, we just have to have agreements that this is a head sound period and I'll be back in two weeks, and a better participant. Lucy: I think that's an important point, that you can in fact give the people who are around you a heads up that this is going on and that you will be back. Stephanie: Right. I think it's definitely something that I learned through relationships and friendships, that what was scary was just going away, even though I knew I'd be back. Lucy: Right. Exactly. Just that simple communication seems like a pretty good tool for one's tool chest. Stephanie: It's not acceptable to miss birthdays and big events, but for the daily check‑ins, or the high‑intensity communication, I just kind of wave my hand and say, "OK, I'll get back to you in a couple of weeks. We're really powering through something." Larry: Stephanie, you might want to check with your mother before you answer this next question. [laughter] Larry: That is, you've already been through and done a great deal. What's next for you? Stephanie: Rogue Paper is actually my third business. The first one is really focused on technology. I actually taught Pilates and had Pilates studios. My life has changed in these big ways. Going back to what we were talking about earlier, that was a system. Pilates is a system, the human body is a system. I was always intrigued by that. This technology, co‑viewing and television, it's applying the same framework to a different type of thing. I would say I'm so excited about Rogue Paper. We're still just about a year and a half old. I feel like we're just really at the precipice of some really interesting things that we can do for media companies and for users. I think mobile penetration is really getting bigger. It's hard for me to think about too much of the future. Maybe I'm a little too comfortable with ambiguity, but I feel like there's so much I want to do now that is at the intersection of mobile media and entertainment. We're really excited about growing. I'm sure my mother would say, "children." Larry: [laughs] Very good. [laughter] Stephanie: "Grandchildren." Lucy: [laughs] Thank you so much for talking to us. You have such a great company, very interesting work. We wish you the very best for the future. We'll be watching, both from a business perspective, and probably we'll be using your technology as well. Stephanie: That is so exciting. Lucy: Yeah. Really. Thanks very much, Stephanie. I want to remind listeners that they can hear this interview at w3w3.com, and ncwit.org, as well as all the other interviews that we've done. Larry: You betcha. Thank you very much, Stephanie. Stephanie: Thank you. Have a great day. Lucy: Thank you, Stephanie. [music] Series: Entrepreneurial HeroesInterviewee: Stephanie BoyleInterview Summary: As a self-proclaimed “TV-holic,” Stephanie Boyle founded Rogue Paper, Inc. to use mobile applications and technology to help enhance traditional media broadcasts and create an engaging double screen experience for viewers. Release Date: August 29, 2011Interview Subject: Stephanie BoyleInterviewer(s): Lucy Sanders, Larry NelsonDuration: 22:06