Podcast appearances and mentions of ruby central

David Hill, the innovative mind behind "Ode to RailsConf" and a senior engineer at Simplify, invites us to explore his fascinating journey into the world of podcasting. Inspired by the final announcement of RailsConf, David crafted a platform to celebrate the cherished memories of the event while also providing himself with a bridge to manage social interactions more comfortably. With his love for board games providing a structured approach, David shares how the podcasting framework has transformed him from a hesitant introvert to a comfortable conversationalist.Our conversation takes an intriguing turn as we delve into the art of podcast guest planning and the intricate process of editing conference videos. From featuring guests from the Scholar Guide program at RailsConf and RubyConf to orchestrating a unique episode with nine guests from a single company, we leave no stone unturned. Engaging discussions with prominent figures like Freedom Dumlao and Sarah May offer listeners a treasure trove of insights, while upcoming episodes with Ruby Central's Rhiannon and Ali Vogel promise to further explore the dynamic world of PR, marketing, and operations.As we navigate the evolution of podcasting strategies, the conversation shifts to the often-overlooked balance between coding and communication. The journey from a simple chat between friends to a thriving podcasting community has not been without its challenges and surprises. We reflect on the impact of Jason Charnes' departure due to family commitments and celebrate the resilience and growth that comes with embracing new roles. Amidst it all, the spirit of supporting creators, learning new skills, and fostering personal growth shines through, with an optimistic outlook for the show's future.Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

Episode OverviewMarty Haught joins Robby to discuss the sustainability of open-source projects, the challenges of maintaining RubyGems, and why the metaphor of technical debt may not fully capture how software ages. Instead, he suggests thinking of it as drift—the natural misalignment of software with its evolving purpose over time.They also dig into security challenges in package management, including how Ruby Central worked with Trail of Bits to audit RubyGems. Marty also shares insights on the EU Cyber Resilience Act and how it might affect open-source maintainers worldwide. Finally, they explore how companies can support open-source sustainability through corporate sponsorships and individual contributions.Topics Discussed[00:01:00] The two pillars of maintainable software: good tests and readability.[00:02:40] From Perl to Ruby: How readability changed Marty's approach to programming.[00:07:20] Is technical debt the right metaphor? Why "drift" might be a better fit.[00:11:00] What does it take to maintain RubyGems? Marty's role at Ruby Central.[00:14:00] Security in package management: How RubyGems handles vulnerabilities.[00:16:40] The role of external audits: Partnering with Trail of Bits for security improvements.[00:20:40] EU Cyber Resilience Act: How new regulations might affect open-source projects.[00:26:00] Funding open source: Why corporate sponsorships are becoming essential.[00:33:40] Advocating for technical debt work in teams: How to make a compelling case.[00:38:20] Processes in distributed teams: Balancing structure with flexibility.Key TakeawaysTechnical debt is often misunderstood. The real issue may not be shortcuts taken in the past, but the way software naturally drifts from its original purpose.Security in package management is a growing concern. Open-source ecosystems like RubyGems require continuous investment to remain secure.Open source needs sustainable funding. Relying on volunteers is not a long-term solution—companies need to contribute via corporate sponsorships.Advocating for code improvements requires strategy. Engineers should frame technical debt discussions around business impact, not just code quality.Resources MentionedMarty Haught on LinkedInMarty Haught on TwitterRuby CentralRubyGemsAuditing the Ruby Ecosystem's Central Package Repository – Trail of BitsEU Cyber Resilience Act OverviewWhat the EU's New Software Legislation Means for Developers (GitHub Blog)Ruby Central Open Source Program – Get InvolvedCorporate Sponsors ProgramGive and Take by Adam GrantConnect with MartyLinkedInTwitterBlueSkyThanks to Our Sponsor!Need a smoother way to share your team's inbox? Jelly's got you covered!

Welcome to the first episode of the new year where Chris and Andrew discuss their holiday activities and recent breaks from work, including travel experiences and Christmas celebrations. They delve into updates on Ruby and Bundler enhancements, and they emphasize the importance of Ruby Central's role in maintaining Ruby's security. The conversation also touches on various tech and entertainment topics including movie reviews, gaming experiences, and smart home projects with Raspberry Pi. The hosts share insights on JSON gem performance improvements and considerations for Ruby's frozen string literals. The episode concludes with discussions on practical applications for Home Assistant and reminiscing about their experiences with different programming languages. Hit download to hear more! HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

On this episode, I'm joined by Adarsh Pandit, Executive Director of Ruby Central.  We discuss men's fashion, Adarsh's path to becoming a developer, the distinction between contracting and consulting, defining what you do as a consultant, keeping yourself top of mind to potential consulting clients, how Ruby Central is building community among Rubyists, the current state of Ruby meetups & conferences, and my conference, Sin City Ruby.Derek Guy on TwitterRubyConfRailsConfrubycentral.orgAdarsh Pandit on LinkedInadarsh@rubycentral.orgSin City Ruby

In this episode, Jason and Chris welcome back Marty Haught, a long-time leader in the Ruby community, to discuss his history and continued involvement with Ruby Central. Marty shares his journey from joining the Ruby Central board in 2012 to his recent role as interim open source lead. The conversation dives into the origins of RubyGems, the evolution of RailsConf and RubyConf, and the challenges of managing these vital aspects of the Ruby ecosystem. Marty also talks about his plans for sustaining RubyGems' future and the infamous "Marty dinner" tradition at conferences. Hit download now to hear more! Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

Ruby Central has been a foundational part of the Ruby community since 2003. They organize Ruby Conf and Rails Conf and maintain critical Ruby infrastructure like rubygems.org. With Ruby Conf Chicago just around the corner and new initiatives at Ruby Central, we thought it would be a good time to catch up with our friends at Ruby Central. Marty Haught joins the show to tell us more about Ruby Central's open source initiatives. Show Notes https://rubyconf.org/ https://rubycentral.org/news/

In this episode, Jason, Chris, and Andrew are joined by the organizers of the RockyMountain Ruby Conference, including Bekki Freeman, Spike Ilacqua, and MartyHaught, discuss their experiences and the journey of building and sustaining the vibrant Ruby community in Colorado. They delve into the challenges and triumphs of organizing the Rocky Mountain Ruby conference, the importance of community meetups, and the inspiration behind their commitment to fostering connections among Ruby developers.They also share their personal motivations, the intricacies involved in conferenceplanning, and the vital role of Ruby Central in supporting regional conferences. Hitdownload now to hear more! Jason Charnes X/Twitter Chris Oliver X/Twitter Andrew Mason X/Twitter

Stephanie and Joël discuss the recent announcement of the call for proposals for RubyConf in November. Joël is working on his proposals and encouraging his colleagues at thoughtbot to participate, while Stephanie is excited about the conference being held in her hometown of Chicago! The conversation shifts to Stephanie's recent work, including completing a significant client project and her upcoming two-week refactoring assignment. She shares her enthusiasm for refactoring code to improve its structure and stability, even when it's not her own. Joël and Stephanie also discuss the everyday challenges of maintaining a test suite, such as slowness, flakiness, and excessive database requests. They discuss strategies to balance the test pyramid and adequately test critical paths. Finally, Joël emphasizes the importance of separating side effects from business logic to enhance testability and reduce complexity, and Stephanie highlights the need to address testing pain points and ensure tests add real value to the codebase. RubyConf CFP (https://sessionize.com/rubyconf-2024/) RubyConf CFP coaching (https://docs.google.com/forms/d/e/1FAIpQLScZxDFaHZg8ncQaOiq5tjX0IXvYmQrTfjzpKaM_Bnj5HHaNdw/viewform?pli=1) Testing pyramid (https://thoughtbot.com/blog/rails-test-types-and-the-testing-pyramid) Outside-in testing (https://thoughtbot.com/blog/testing-from-the-outsidein) Writing fewer system specs with request specs (https://thoughtbot.com/blog/faster-tests-with-capybara-and-request-specs) Unnecessary factories (https://thoughtbot.com/blog/speed-up-tests-by-selectively-avoiding-factory-bot) Your Test Suite is Making Too Many Database Calls (https://www.youtube.com/watch?v=LOlG4kqfwcg) Your flaky tests might be time dependent (https://thoughtbot.com/blog/your-flaky-tests-might-be-time-dependent) The Secret Ingredient: How To Understand and Resolve Just About Any Flaky Test (https://www.youtube.com/watch?v=De3-v54jrQo) Separating side effects to improve tests (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) Functional core, imperative shell (https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell) Thoughtbot testing articles (https://thoughtbot.com/blog/tags/testing) 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 that's new in my world is that RubyConf just announced their call for proposals for RubyConf in November. They're open for...we're currently recording in June, and it's open through early July, and they're asking people everywhere to submit talk ideas. I have a few of my own that I'm working with. And then, I'm also trying to mobilize a lot of other colleagues at thoughtbot to get excited to submit. STEPHANIE: Yes, I am personally very excited about this year's RubyConf in November because it's in Chicago, where I live, so I have very little of an excuse not to go [laughs]. I feel like so much of my conference experience is traveling to just kind of, like, other cities in the U.S. that I want to spend some time in and, you know, seeing all of my friends from...my long-distance friends. And it definitely does feel like just a bit of an immersive week, right? And so, I wonder how weird it will feel to be going to this conference and then going home at the end of the night. Yeah, that's just something that I'm a bit curious about. So, yeah, I mean, I am very excited. I hope everyone comes to Chicago. It's a great city. JOËL: I think the pitch that I'm hearing is submit a proposal to the RubyConf CFP to get a chance to get a free ticket to go to RubyConf, where you get to meet Bike Shed co-host Stephanie Minn. STEPHANIE: Yes. Ruby Central should hire me to market this conference [laughter] and that being the main value add of going [laughs], obviously. Jokes aside, I'm excited for you to be doing this initiative again because it was so successful for RailsConf kind of internally at thoughtbot. I think a lot of people submitted proposals for the first time with some of the programming you put on. Are you thinking about doing things any differently from last time, or any new thoughts about this conference cycle? JOËL: I think I'm iterating on what we did last time but trying to keep more or less the same formula. Among other things, people don't always have ideas immediately of what they want to speak about. And so, I have a brainstorming session where we're just going to get together and brainstorm a bunch of topics that are free for anyone to take. And then, either someone can grab one of those topics and pitch a talk on it, or it can be, like, inspiration where they see that it jogs their mind, and they have an idea that then they go off and write a proposal. And so, that allows, I think, a lot of colleagues as well, who are maybe not interested in speaking but might have a lot of great ideas, to participate and sort of really get a lot of that energy going. And then, from there, people who are excited to speak about something can go on to maybe draft a proposal. And then, I've got a couple of other events where we support people in drafting a proposal and reviewing and submitting, things like that. STEPHANIE: Yes, I really love how you're just involving people with, you know, just different skills and interests to be able to support each other, even if, you know, there's someone on our team who's, like, not interested in speaking at all, but they're, like, an ideas person, right? And they would love to see their idea come to life in a talk from someone else. Like, I think that's really cool, and I certainly appreciate it as a not ideas person [laughs]. JOËL: Also, I want to shout out that Ruby Central is doing CFP coaching sessions on June 24th, June 25th, and June 26th, and those are open to anyone. You can sign up. We'll put a link to the signup form in the show notes. If you've never submitted something before and you'd like some tips on what makes for a good CFP, how can you up your chances of getting accepted, or maybe you've submitted before, you just want to get better at it; I recommend joining one of those slots. So, Stephanie, what's new in your world? STEPHANIE: So, I just successfully delivered a big project on my client work last week. So, I'm kind of riding that wave and getting into the next bit of work that I have been assigned for this team, and I'm really excited to do this. But I also, I don't know, I've been just, like, thinking about it quite a bit. Basically, I'm getting to spend two dedicated weeks to just refactoring [laughs] some really, I guess, complicated code that has led to some bugs recently and just needing some love, especially because there's some whiffs of potentially, like, really investing in this area of the product, and people wanting to make sure that the foundation does feel very stable to build on top of for extending and changing that code. And I think I, like, surprised myself by how excited I was to do this because it's not even code I wrote. You know, sometimes when you are the one who wrote code, you're like, oh, like, I would love time to just go back and clean up all these things that I kind of missed the first time around or just couldn't attend to for whatever reason. But yeah, I think I was just a little bit in the peripheries of that code, and I was like, oh, like, just seeing some weird stuff. And now to kind of have the time to be like, oh, this is all I'm going to be doing for two weeks, to, like, really dive into it and get my hands dirty [laughs], I'm very excited. JOËL: I think that refactoring is a thing that can be really fun. And also, when you have a larger chunk of time, like two days, it's easy to sort of get lost in sort of grand visions or projects. How do you kind of balance the, I want to do a lot of refactoring; I want to take on some bigger things while maybe trying to keep some focus or have some prioritization? STEPHANIE: Yeah, that's a great question. I was actually the one who said, like, "I want two weeks on this." And it also helped that, like, there was already some thoughts about, like, where they wanted to go with this area of the codebase and maybe what future features they were thinking about. And there are also a few bugs that I am fixing kind of related to this domain. So, I think that is actually what I started with. And that was really helpful in just kind of orienting myself in, like, the higher impact areas and the places that the pain is felt and exploring there first to, like, get a sense of what is going on here. Because I think that information gathering is really important to be able to kind of start changing the code towards what it wants to be and what other devs want it to be. I actually also started a thread in Slack for my team. I was, like, asking for input on what's the most confusing or, like, hard to reason about files or areas in this particular domain or feature set and got a lot of really good engagement. I was pleasantly surprised [laughs], you know, because sometimes you, like, ask for feedback and just crickets. But I think, for me, it was very affirming that I was, like, exploring something that a lot of people are like, oh, we would love for someone to, you know, have just time to get into this. And they all were really excited for me, too. So, that was pretty cool. JOËL: Interesting. So, it sounds like you sort of budgeted some refactoring time and then, from there, broke it down into a series of a couple of debugging projects and then a couple of, like, more bounded refactoring projects, where, like, specifically, I want to restructure the way this object works or something like that. STEPHANIE: Yeah. I think there was that feeling of wanting to clean up this area of the codebase, but you kind of caught on to that bit of, you know, it can go so many different ways. And, like, how do you balance your grand visions [laughs] of things with, I guess, a little bit of pragmatism? So, it was very much like, here's all these bugs that are causing our customers problems that are kind of, like, hard for the devs to troubleshoot. You know, that kind of prompts the question, like, why? And so, if there can be, you know, the fixing of the bugs, and then the learning of, like, how that part of the system works, and then, hopefully, some improvements along the way, yeah, that just felt like a dream [laughs] for me. And two weeks felt about the right amount of time. I don't know if anyone kind of hears that and feels like it's too long or too little. I would be really curious. But I feel like it is complex enough that, like, context switching would, I think, make this work harder, and you kind of do have to just sit with it for a little bit to get your bearings. JOËL: A scenario that we encounter on a pretty regular basis is a customer coming to us and telling us that they're feeling a lot of test pain and asking what are the ways that we can help them to make things better and that test pain can come under a lot of forms. It might be a test suite that's really slow and that's hurting the team in terms of their velocity. It might be a test suite that is really flaky. It might be one that is really difficult to add to, or maybe one that has very low coverage, or one that is just really brittle. Anytime you try to make a change to it, a bunch of things break, and it takes forever to ship anything. So, there's a lot of different aspects of challenging test suites that clients come to us with. I'm curious, Stephanie, what are some of the ones that you've encountered most frequently? STEPHANIE: I definitely think that a slow test suite and a flaky test suite end up going hand in hand a lot, or just a brittle one, right? That is slowing down development and, like you said, causing a lot of pain. I think even if that's not something that a client is coming to us directly about, it maybe gets, like, surfaced a little bit, you know, sometime into the engagement as something that I like to keep an eye on as a consultant. And I actually think, yeah, that's one of kind of the coolest things, I think, about our consulting work is just getting to see so many different test suites [laughs]. I don't know. I'm a testing nerd, so I love that kind of stuff. And then, I think you were also kind of touching on this idea of, like, maintaining a test suite and, yeah, making testing just a better experience. I have a theory [laughs], and I'd be curious to get your thoughts on it. But one thing that I really struggle with in the industry is when people talk about writing tests as if it's, like, the morally superior thing to do. And I struggle with this because I don't think that it is a very good strategy for helping people feel better or more confident and, like, upskill at writing tests. I think it kind of shames people a little bit who maybe either just haven't gotten that experience or, you know, just like, yeah, like, for whatever reason, are still learning how to do this thing. And then, I think that mindset leads to bad tests [laughs] or tests that aren't really serving the purpose that you hope they would because people are doing it more out of obligation rather than because they truly, like, feel like it adds something to their work. Okay, I kind of just dropped that on you [laughs]. Do you have any reactions? JOËL: Yeah, I guess the idea that you're just checking a box with your test rather than writing code that adds value to the codebase. They're two very different perspectives that, in the end, will generate more lines of code if you're just doing a checkbox but may or may not add a whole lot of value. So, maybe before even looking at actual, like, test practices, it's worth stepping back and asking more of a mindset question: Why does your team test? What is the value that your team feels they get out of testing? STEPHANIE: Yeah. Yeah. I like that because I was about to say they go hand in hand. But I do think that maybe there is some, you know, question asking [laughs] to be done because I do think people like to kind of talk about the testing practices before they've really considered that. And I am, like, pretty certain from just kind of, at least what I've seen, and what I've heard, and what I've experienced on embedding into client teams, that if your team can't answer that question of, like, "What value does testing bring?" then they probably aren't following good testing practices [laughs]. Because I do think you kind of need to approach it from a perspective of like, okay, like, I want to do this because it helps me, and it helps my team, rather than, like you said, getting the check mark. JOËL: So, once we've sort of established maybe a bit of a mindset or we've had a conversation with the team around what value they think they're getting out of tests, or maybe even you might need to sell the team a little bit on like, "Hey, here's, like, all these different ways that testing can bring value into your life, make your life as developers easier," but once you've done that sort of pre-work and you can start looking at what's actually the problem with a test suite, a common complaint from developers is that the test suite is too slow. How do you like to approach a slow test suite? STEPHANIE: That's a good question. I actually...I think there's a lot of ways to answer that. But to kind of stay on the theme of stepping back a little bit, I wonder if assessing how well your test suite aligns with the testing pyramid would be a good place to start; at least, that could be where I start if I'm coming into a client team for the first time, right, and being asked to start assessing or just poking around. Because I think the slowness a lot of the time comes from a lot of quote, unquote, "integration tests" or, like, unit tests masquerading as integration tests, where you end up having, like, a lot of duplication of things that are being tested in ways that are integrating with some slow parts of the system like the database. And yeah, I think even before getting into some of the more discreet reasons why you might be writing slow tests, just looking at the structure of your test suite and what kinds of things you're testing, and, again, even going back to your team and asking, like, "What kinds of things do you test?" Or like, "Do you try to test or wish to be testing more of, less of?" Like looking at the structure, I have found to be a good place to start. JOËL: And for those who are not familiar, you used the term testing pyramid. This is a concept which says that you probably want to have a lot of small, fast unit tests, a medium amount of integration tests that test a few different components together, and then a few end-to-end tests. Because as you go up that pyramid, tests become more expensive. They take a lot longer to run, whereas the little unit tests are super cheap. You can create thousands of them, and they will barely impact your run time. Adding a dozen end-to-end tests is going to be noticeable. So, you want to balance sort of the coverage that you get from end to end with the sort of cheapness and ubiquity of the little unit tests, and then split the difference for tests that are in between. STEPHANIE: And I think that is challenging, even, you know, you're talking about how you want the peak of your pyramid to be end-to-end tests. So, you don't want a lot of them, but you do want some of them to really ensure that things are totally plumbed and working correctly. But that does require, I think, really looking at your application and kind of identifying what features are the most critical to it. And I think that doesn't get paid enough attention, at least from a lot of my client experiences. Like, sometimes teams just end up with a lot of feature bloat and can't say like, you know, they say, "Everything's important [chuckles]," but everything can't be equally important, you know? JOËL: Right. I often like to develop using a sort of outside-in approach, where you start by writing an end-to-end test that describes the behavior that your new feature ticket is asking for and use that to drive the work that I'm doing. And that might lead to some lower-level unit tests as I'm building out different components, but the sort of high-level behavior that we're adding is driven by adding an end-to-end spec. Do you feel that having one new end-to-end spec for every new feature ticket that you work on is a reasonable thing to do, or do you kind of pick and choose? Do you write some, but maybe start, like, coalescing or culling them, or something like that? How do you manage that idea that maybe you would or would not want one end-to-end spec for each feature ticket? STEPHANIE: Yeah, it's a good question. Actually, as you were saying that, I was about to ask you, do you delete some afterwards [laughs]? Because I think that might be what I do sometimes, especially if I'm testing, you know, edge cases or writing, like, the end-to-end test for error states. Sometimes, not all of them make it into my, like, final, you know, commit. But they, you know, had their value, right? And at least it prompted me to make sure I thought about them and make sure that they were good error states, right? Like things that had visible UI to the user about what was going on in case of an error. So, I would say I will go back and kind of coalesce some of them, but they at least give me a place to start. Does that match your experience? JOËL: Yeah, I tend to mostly write end-to-end tests for happy paths and then write kind of mid-level things to cover some of my edge cases, maybe a couple of end-to-end tests for particularly critical paths. But, at some point, there's just too many paths through the app that you can't have end-to-end coverage for every single branch on every single path that can happen. STEPHANIE: Yeah, I like that because if you find yourself having a lot of different conditions that you need to test in an end-to-end situation, maybe there's room for that to, like, be better encapsulated in that, like, more, like, middle layer or, I don't know, even starting to ask questions about, like, does this make sense with the product? Like, having all of these different things going on, does that line up with kind of the vision of what this feature is trying to be or should be? Because I do think the complexity can start at that high of a level. JOËL: How do you feel about the idea that adding more end-to-end tests, at some point, has diminishing returns? STEPHANIE: I'm not quite sure I'm following [laughs]. JOËL: So, let's say you have an end-to-end test for the happy path for every core feature of the app. And you decide, you know what, I want to add maybe some, like, side features in, or maybe I want to have more error states. And you start, like, filling in more end-to-end tests for those. Is it fair to say that adding some of those is a bit of a diminishing return? Like, you're not getting as much value as you would from the original specs. And maybe as you keep finding more and more rare edge cases, you get less and less value for your test. STEPHANIE: Oh, yeah, I see. And there's more of a cost, too, right? The cost of the time to run, maintain, whatever. JOËL: Right. Let's say they're roughly all equally expensive in terms of cost to run. But as you stray further and further off of that happy path, you're getting less and less value from that integration test or that end-to-end test. STEPHANIE: I'm actually a little conflicted about this because that sounds right in theory, but then in practice, I feel like I've seen error states not get enough love [laughs] that it's...I don't even want to say, like, you make any kind of claim [laughs] about it. But, you know, if you're going to start somewhere, if you have, like, a limited amount of time and you're like, okay, I'm only going to write a handful of end-to-end tests, yeah, like, write tests for your happy paths [laughs]. JOËL: I guess it's probably fair to say that error states just don't get as much love as they should throughout the entire testing stack: at the unit level, at the integration level, all the way up to end to end. STEPHANIE: I'm curious if you were trying to get at some kind of conclusion, though, with the idea of diminishing returns. JOËL: I guess I'm wondering if, from there, we can talk about maybe a breakdown of a particular testing pyramid for a particular test suite is being top heavy, and whether there's value in maybe pushing some of these tests, some of these edge cases, some of these maybe less important features down from that, like, top end-to-end layer into maybe more of an integration layer. So, in a Rails context, that might be moving system specs down to something like a request spec. STEPHANIE: Yeah, I think that is what I tend to do. I'm trying to think of how I get there, and I'm not quite sure that I can explain it quite yet. Yeah, I don't know. Do you think you can help me out here? Like, how do you know it's time to start writing more tests for your unhappy paths lower on the pyramid? JOËL: Ideally, I think a lot of your code should be unit-tested. And when you are unit testing it, those pieces all need coverage of the happy and unhappy paths. I think the way it may often happen naturally is if you're pushing logic out of your controllers because it's a little bit challenging sometimes to test Rails controllers. And so, if you're moving things into domain objects, even service objects, depending on how you implement them, just doing that and then making sure you unit test them can give you a lot more coverage of all the different edge cases that can happen. Where things sometimes fall apart is getting out of that business layer into the web layer and saying, "Hey, if something raises an error or if the save fails or something like that, does the user get a good experience, or do we just crash and give them a 500 page?" STEPHANIE: Yeah, that matches with a lot of what I've seen, where if you then spend too much time in that business layer and only handling errors there, you don't really think too much about how it bubbles up. And, you know, then you are digging through, like, your error monitoring [laughs] service, trying to find out what happened so that you can tell, you know, your customer support team [laughs] to help them resolve, like, a bug report they got. But I actually think...and you were talking about outside in, but, in some ways, in my experience, I also get feedback from the bottom up sometimes that then ends up helping me adjust some of those integration or end-to-end tests about kind of what errors are possible, like, down in the depths of the code [laughs], and then finding ways to, you know, abstract that or, like, kind of be like, "Oh, like, here are all these possible, like, exceptions that might be raised." Like, what HTTP status code do I want to be returned to capture all of these things? And what do I want to say to the user? So, yeah, I'm [laughs] kind of a little lost myself, but this idea that going both, you know, outside in and then maybe even going back up a little bit has served me well before. JOËL: I think there can be a lot of value in sort of dropping down a level in the pyramid, and maybe instead of doing sort of end-to-end tests where you, like, trigger a scenario where something fails, you can just write a request back against the controller and say, "Hey, if I go to this controller and something raises an error, expect that you get redirected to this other location." And that's really cheap to run compared to an end-to-end test. And so, I think that, for me, is often the right compromise is handling error states at sort of the next lowest level and also in slightly more atomic pieces. So, more like, if you hit this endpoint and things go wrong, here's how things happen. And I use endpoint not so much in an API sense, although it could be, but just your, you know, maybe you've got a flow that's multiple steps where, you know, you can do a bunch of things. But I might have a test just for one controller action to say, "Hey, if things go wrong, it redirects you here, or it shows you this error page." Whereas the end-to-end test might say, "Oh, you're going to go through the entire flow that hits multiple different controllers, and the happy path is this nice chain." But each of the exit points off at where things fail would be covered by a more scoped request spec on that controller. STEPHANIE: Yeah. Yeah. That makes sense. I like that. JOËL: So, that's kind of how I've attempted to balance my pyramid in a way that balances complexity and time with coverage. You mentioned that another area that test suites get slow is making too many requests to the database. There's a lot of ways that that happens. Oftentimes, I think a classic is using a factory where you really don't need to, persisting data to the database when all you needed was some object in memory. So, there are different strategies for avoiding that. It's also easy to be creating too much data. So, maybe you do need to persist some things in the database, but you're persisting a hundred objects into memory or into the database when you really meant to persist two, so that's an easy accident. A couple of years ago, I gave a talk at RailsConf titled "Your Test Suite is Making Too Many Database Requests" that went over a bunch of different ways that you can be doing a lot of expensive database requests you didn't plan on making and how that slows down your test suite. So, that is also another hot spot that I like to look at when dealing with a slow test suite. STEPHANIE: Yeah, I mentioned earlier the idea of unit tests really masquerading as integration tests [laughs]. And I think that happens especially if you're starting with a class that may already be a little bit too big than it should be or have more responsibilities than it should be. And then, you are, like, either just, like, starting with using the create build, like, strategy with factories, or you find yourself, like, not being able to fully run the code path you're trying to test without having stuff persisted. Those are all, I think, like, test smells that, you know, are signaling a little bit of a testing anti-pattern that, yeah, like, is there a way to write, like, true unit tests for this stuff where you are only using objects in memory? And does that require breaking out some responsibilities? That is a lot of what I am kind of going through right now, actually, with my little refractoring project [laughs] is backfilling some tests, finding that I have to create a lot of records. And you know what? Like, the first step will probably be to write those tests and commit them, and just have them live there for a little while while I figure out, you know, the right places to start breaking things up, and that's okay. But yeah, I did want to, like, just mention that if you are having to create a lot of records and then also noticing, like, your test is running kind of slow [laughs], that could be a good indicator to just give a good, hard look at what kind of style of test you think you're writing [laughs]. JOËL: Yeah, your tests speak to you, and when you're feeling pain, oftentimes, it can be a sign that you should consider refactoring your implementation. And I think that's doubly true if you're writing tests after the fact rather than test driving. Because sometimes you sort of...you came up with an implementation that you thought would be good, and then you're writing tests for it, and it's really painful. And that might be telling you something about the underlying implementation that you have that maybe it's...you thought it's well scoped, but maybe it actually has more responsibilities than you initially realized, or maybe it's just really tightly coupled in a way that you didn't realize. And so, learning to listen to your tests and not just sort of accepting the world for being the way it is, but being like, "No, I can make it better." STEPHANIE: Yeah, I've been really curious why people have a hard time, like, recognizing that pain sometimes, or maybe believing that this is the way it is and that there's not a whole lot that you can do about it. But it's not true, like, testing really does not have to be painful. And I feel like, again, this is one of those things that's like, it's hard to believe until you really experience it, at least, that was the case for me. But if you're having a hard time with tests, it's not because you're not smart enough. Like, that, I think, is a thing that I really want to debunk right now [laughs] for anyone who has ever had that thought cross their mind. Yeah, things are just complicated and complex somehow, or software entropy happens. That's, like, not how it should be, and we don't have to accept that [laughs]. So, I really like what you said about, oh, you can change it. And, you know, that is a bit of a callback to the whole mindset of testing that we mentioned earlier at the beginning. JOËL: Speaking of test suites, we have not covered yet is paralyzing it. That could probably be its own Bike Shed episode on its own entirely on paralyzing a test suite. We've done entire engagements where our job was to come in and help paralyze a test suite, make it faster. And there's a lot of, like, pros and cons. So, I think maybe we can save that for a different episode. And, instead, I'd like to quickly jump in a little bit to some other common pain points of test suites, and I would say probably top of that list is test flakiness. How do you tend to approach flakiness in a client project? STEPHANIE: I am, like, laughing to myself a little bit because I know that I was dealing with test flakiness on my last client engagement, and that was, like, such a huge part of my day-to-day is, like, hitting that retry button. And now that I am on a project with, like, relatively low flakiness, I just haven't thought about it at all [laughs], which is such a privilege, I think [laughs]. But one of the first things to do is just start, like, capturing metrics around it. If you, you know, are hearing about flakiness or seeing that, like, start to plague your test suite or just, you know, cropping up in different ways, I have found it really useful to start, like, I don't know, just, like, maybe putting some of that information in a dashboard and seeing how, just to, like, even make sure that you are making improvements, that things are changing, and seeing if there's any, like, patterns around what's causing the flakiness because there are so many different causes of it. And I think it is pretty important to figure out, like, what kind of code you're writing or just trying to wrangle. That's, you know, maybe more likely to crop up as flakiness for your particular domain or application. Yeah, I'm going to stop there and see, like, because I know you have a lot of thoughts about flakiness [laughs]. JOËL: I mean, you mentioned that there's a lot of different causes for flakiness. And I think, in my experience, they often sort of group into, let's say, like, three different buckets. Anytime you're testing code that's doing things that are non-deterministic, that's easy for tests to be flaky. And so, you might think, oh, well, you know, you have something that makes a call to random, and then you're going to assert on a particular outcome of that. Well, clearly, that's going to not be the same every time, and that might be flaky. But there are, like, more subtle versions of that, so maybe you're relying on the system clock in some way. And, you know, depending on the time you run that test, it might give you a different value than you expect, and that might cause it to fail. And it doesn't have to be you're asserting on, like, oh, specifically a given millisecond. You might be doing math around, like, number of days, and when you get near to, let's say, the daylight savings boundary, all of a sudden, no, you're off by an hour, and your number of days...calculation breaks because relying on the clock is something that is inherently non-deterministic. Non-determinism is a bucket. Leaky tests is another bucket of failures that I see, things where one test might impact another that gets run after the fact, oftentimes by mutating some sort of global state. So, maybe you're both relying on some sort of, like, external file that you're both writing to or maybe a cache that one is writing to that the other one is reading from, something like that. It could even just be writing records into the database in a way that's not wrapped in a transaction, such that there's more data in the database when the next test runs than it expects. And then, finally, if you are doing any form of parallelization, that can improve your test suite speed, but it also potentially leads to race conditions, where if your resources aren't entirely isolated between parallel test runners, maybe you're sharing a database, maybe you're sharing Redis instance or whatever, then you can run into situations where you're both kind of fighting over the same resources or overriding each other's data, or things like that, in a way that can cause tests to fail intermittently. And I think having a framework like that of categorization can then help you think about potential solutions because debugging approaches and then solutions tend to be a little bit different for each of these buckets. STEPHANIE: Yeah, the buckets of different causes of flaky tests you were talking about, I think, also reminded me that, you know, some flakiness is caused by, like, your testing environment and your infrastructure. And other kinds of flakiness are maybe caused more from just the way that you've decided how your code should work, especially that, like, non-deterministic bucket. So, yeah, I don't know, that was just, like, something that I noticed as you were going through the different categories. And yeah, like, certainly, the solutions for approaching each kind are very different. JOËL: I would like to pitch a talk from RubyConf last year called "The Secret Ingredient: How To Resolve And Understand Just About Any Flaky Test" by Alan Ridlehoover. Just really excellent walkthrough of these different buckets and common debugging and solving approaches to each of them. And I think having that framework in mind is just a great way to approach different types of flaky tests. STEPHANIE: Yes, I'll plus one that talk, lots of great pictures of delicious croissants as well. JOËL: Very flaky pastry. STEPHANIE: [laughs] Joël, do you have any last testing anti-pattern guidances for our audience who might be feeling some test pain out there? JOËL: A quick list, I'm going to say tight coupling that has then led to having a lot of stubbing in your tests often leads to tests that are very brittle, so tests that maybe don't fail when they should when you've actually broken things, or maybe, alternatively, tests that are constantly failing for the wrong reasons. And so, that is a thing that you can fix by making your code less coupled. Tests that also require stubbing a lot of things because you do a lot of side effects. If you are making a lot of HTTP calls or things like that, that can both make a test more complex because it has to be aware of that. But also, it can make it more non-deterministic, more flaky, and it can just make it harder to change. And so, I have found that separating side effects from sort of business logic is often a great way to make your test suite much easier to work with. I have a blog post on that that I'll link in the show notes. And I think this maybe also approaches the idea of a functional core and an imperative shell, which I believe was an idea pitched by Gary Bernhardt, like, over ten years ago. There's a famous video on that that we'll also link in the show notes. But that architecture for building an app can lead to a much nicer test to write. I guess the general idea being that testing code that does side effects is complicated and painful. Testing code that is more functional tends to be much more pleasant. And so, by not intermingling the two, you tend to get nicer tests that are easier to maintain. STEPHANIE: That's really interesting. I've not heard that guidance before, but now I am intrigued. That reminded me of another thing that I had a conversation with someone about. Because after the RailsConf talk I gave, which was about testing pain, there was some stubbing involved in the examples that I was showing because I just see a lot of that stuff. And, you know, this audience member kind of had that question of, like, "How do you know that things are working correctly if you have to stub all this stuff out?" And, you know, sometimes you just have to for the time being [chuckles]. And I wanted to just kind of call back to that idea of having those end-to-end tests testing your critical paths to at least make sure that those things work together in the happy way. Because I have seen, especially with apps that have a lot of service objects, for some reason, those being kind of the highest-level test sometimes. But oftentimes, they end up not being composed well, being quite coupled with other service objects. So, you end up with a lot of stubbing of those in your test for them. And I think that's kind of where you can see things start to break down. JOËL: Yep. And when the RailsConf videos come out, I recommend seeing Stephanie's talk, some great gems in there for building a more maintainable test suite. Stephanie and I and, you know, most of us here at thoughtbot, we're testing nerds. We think about this a lot. We've also written a lot about this. There are a lot of resources in the show notes for this episode. Check them out. Also, just generally, check out the testing tag on the thoughtbot blog. There is a ton of content there that is worth looking into if you want to dig further into this topic. STEPHANIE: Yeah, and if you are wanting some, like, dedicated, customized testing training, thoughtbot offers an RSpec workshop that's tailored to your team. And if you kind of are interested in the things we're sharing, we can definitely bring that to your company as well. 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: Byeeeeeeeee!!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at: referrals@thoughtbot.com with any questions.

Ever wondered how a Ruby developer transitions into a successful entrepreneur? Join us as Josh Wood, co-founder of HoneyBadger.io, shares his fascinating journey. From creating notable projects like the Heya gem and Exceptional Creatures to spearheading the launch of HoneyBadger Insights, Josh offers an insider's view of the Ruby community and his experiences at RailsConf. Listen to his unique perspective on balancing developer relations, marketing, and the dynamic energy that fuels his passion for Ruby development.Curious about the latest trends in Ruby conferences? This episode dives into the vibrant world of Ruby events across the U.S. and Europe. We discuss the allure of gatherings like Blue Ridge and Rocky Mountain Ruby, along with smaller, community-driven meetups such as Ruby on Trails and Rawhide Ruby. Learn about the shift in Ruby Central's focus from organizing RailsConf to empowering regional conferences and ponder the potential rise of new events in cities like Philadelphia. Josh and his co-founder Ben Curtis's collaborative dynamics and quarterly strategy meetings are also on the agenda.What does it take to reposition a well-known error tracker into a comprehensive application performance monitoring tool? Josh reveals the strategic shifts at HoneyBadger, unpacking the challenges of marketing and design from the vantage point of a technical founder. Hear about the creative process behind naming projects, the nostalgic joy of using older technologies, and the interplay between personal hobbies and professional life. This episode promises a rich blend of insights and stories that will captivate anyone interested in the intersection of technology, entrepreneurship, and community culture.Send us some love.HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.Support the Show.Ready to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

In this episode of Remote Ruby, host Chris is joined by guests Kent Crutchfield andCollin Jilbert, sharing their experiences and reflections from the recent RailsConf inDetroit, MI. They discuss various aspects of the conference, including the engagingtalks, the announcement of RailsConf's impending conclusion in favor of focusing onRubyConf and regional events, and their personal interactions with other attendees. Theepisode highlights how RailsConf facilitated meaningful community interactions,supported professional growth through the Scholars and Guides Program, providedinsights into the practical applications and potential of Ruby on Rails technology,acknowledgements of the hard work behind RailsConf organization, and a call tocontinue supporting Ruby Central. Press download to hear much more!HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

In this episode of Maintainable, our host Robby Russell sits down with Martin Emde, a sage in the Ruby community and the current Director of Open Source at Ruby Central. Together, they weave through the intricacies of maintainable software, legacy code, and the unwavering power of the Ruby ecosystem. Martin, with his wealth of experience, shares tales from the trenches of open-source software development, focusing on RubyGems and Bundler, and how they've evolved to face the challenges of modern software needs.Martin addresses the elephant in the room - complexity in software. He muses on the natural progression of software projects from simplicity to complexity, drawing parallels to the growth of living organisms. It's not about fighting complexity, but embracing it with open arms, ensuring the software remains adaptable and maintainable. This conversation sheds light on the importance of testing, documentation, and community support in navigating the seas of complex software development.Diving deeper, they discuss the essence of technical debt, not as a villain in our stories but as a necessary step in the rapid evolution of technology. Martin's perspective on technical debt as a tool for progress rather than an obstacle is refreshing, encouraging developers to approach their work with more kindness and understanding.The discussion also highlights Ruby Central's pivotal role in nurturing the Ruby community, emphasizing the importance of contributions, whether code, conversation, or financial support. Martin's call to action for developers to engage with open-source projects, to adopt gems in need, and to provide support where possible, is a heartwarming reminder of the collective effort required to sustain the vibrant Ruby ecosystem.For those curious minds eager to dive into the world of Ruby, contribute to its growth, or simply enjoy a captivating discussion on software development, this episode is a delightful journey through the challenges and joys of maintaining open-source software. Don't miss out on the gems of wisdom shared in this episode, and be sure to check out the useful links below for more information on how you can contribute to the Ruby community.Book Recommendation:Project Hail Marry by Andy WeirHelpful Links:BundlerRuby CentralAdopt a GemMartin on GithubMartin's websiteThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and soon, other frameworks. It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications. Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of 'Ruby For All', hosts Andrew and Julie welcome guest Kevin Murphy, Software Developer at Pubmark and member of the RailsConf program committee. The discussion kicks off with Andrew and Julie catching up, then transitions into an in-depth conversation about the RailsConf planning process. Kevin and Julie, the Speaker Liaison, share insights into the workings of the program committee, the selection criteria for conference talks, and the challenges and rewards of organizing RailsConf. Additionally, Kevin elaborates on his role in the committee, the theme for this year's conference, and his goals for impact, and Julie looks forward to supporting speakers and managing workshops. The episode emphasizes the importance of volunteer contributions to the success of RailsConf and encourages attendees to express their gratitude to the organizers, and to go check out all the details at RailsConf.org and buy your tickets now!  Press download to hear more! [00:00:15] Andrew and Julie catch up, Andrew overslept after finishing a project, Julie was up late watching videos, and Andrew recommends the show “Invincible.”[00:02:22] Kevin introduces himself and explains why he likes working with Ruby on Rails. [00:03:37] Kevin discusses the role of the RailsConf program committee, explains their responsibilities, including reviewing proposals and scheduling talks. [00:05:10] We learn what Kevin looks for in a conference talk proposal, emphasizing relevance to the theme and potential audience interest. Julie shares her perspective on reviewing proposals, considering both her emotional response and broader interests. [00:07:38] Kevin shares his first experience on the committee and discusses the time commitment involved and talks about the fairness of reviewing all proposals at once after the submission deadline. [00:11:03] Julie expresses her difficulty with the proposal reviewing process, suggesting that a grading scale might have been more effective for her. Kevin reflects on the surprises of the reviewing process and the difference between his perceptions and the rankings generated by the review system. [00:12:41] Julie adds that the difficulty in having to reject good talks due to overlapping topics or because they might fit better at another conference like RubyConf,[00:13:09] Andrew asks if the proposers receive feedback on why their talks may be more suited for RubyConf, and Kevin explains that if they ask, Ruby Central will make their best effort to provide it.[00:14:47] What's been the most rewarding part of this experience for Kevin and Julie? Kevin finds the opportunity to impact the community through the program committee rewarding, and Julie says she's waiting to see the full impact of her role as Speaker Liaison, which involves making speakers feel supported and pairing them with mentors.[00:16:24] Kevin and Julie both explain how they were invited to join the program committee by Ufuk, who's a member of the Ruby Central board, and Julie brings up a previous episode with Kevin on conference speaking. [00:17:52] Andrew asks what Kevin and Julie think the hardest part of will be being on the program committee at the conference. Kevin hopes his committee responsibilities won't impact his conference experience too much, and Julie anticipates the challenge of not having as much personal downtime during the conference due to her responsibilities. [00:19:41] Kevin reflects on the subjective nature of selecting talks and how different perceptions among committee members can affect decisions. He emphasizes that rejected talks are not necessarily of poor quality but may not fit due to other reasons.[00:21:02] Julie inquires about Kevin's role on the program committee and how he feels so far. His role involves scheduling and organizing accepted talks and workshops, reviewing and giving feedback on rejected proposals, and just being available.[00:22:00] Julie's role is Speaker Liaison, helping speakers with their needs and feeling special, and helping with scheduling workshops. Kevin clarifies the concept of tracks at conferences and since there aren't any this year, the goal is to align all talks with the overall theme of building with Rails. Julie mentions a blog post written by Kevin about the absence of tracks at RailsConf.[00:23:28] Kevin shares his aspirations for his impact on RailsConf: ensuring a safe, educational experience for attendees, seeing first-time speakers succeed, and enjoying the mentorship process. Julie describes her motivation for becoming a Speaker Liaison: to provide a supportive experience for speakers. [00:25:03] RailsConf is happening in Detroit, May 7-9. Kevin expresses his excitement for various aspects, including the strong program and meeting friends, and urges everyone to visit RailsConf.org, check the schedule, and get tickets. [00:28:19] Find out where you can follow Kevin online. Panelists:Andrew MasonJulie JGuest:Kevin MurphySponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteKevin Murphy WebsitePubmarkRuby for All Podcast-Episode 50: The Art of Conference Speaking with Kevin MurphyTracks Not At RailsConf 2024-by Kevin MurphyRailsConf-Detroit May 7-9, 2024RailsConf ScheduleRailsConf SpeakersInvincible: Season 2 (Amazon Prime) (00:00) - Introduction and Casual Catch-Up (02:22) - Guest Introduction: Kevin Murphy on Ruby and Rails (03:37) - Inside the RailsConf Program Committee: Roles and Responsibilities (05:10) - What Makes a Great Conference Talk? Selection Criteria Explored (07:38) - Behind the Scenes: Reviewing Conference Proposals (11:03) - Challenges in Proposal Review: Fairness and Surprises (12:41) - Rejection Reasons: When Good Talks Don't Make the Cut (13:09) - Feedback for Rejected Proposals: Bridging to RubyConf (14:47) - Rewarding Aspects of Program Committee Work (16:24) - Joining the Program Committee: Invitations and Insights (17:52) - Preparing for RailsConf: Expectations and Challenges (19:41) - The Subjectivity of Talk Selection: A Committee Perspective (21:02) - Roles Deep Dive: Organizing Talks and Supporting Speakers (23:28) - Goals and Aspirations for RailsConf Impact (25:03) - RailsConf 2023 Preview: What to Expect in Detroit

Discover the heartbeat of Ruby with Ufuk Kayserilioglu, the engineering maestro at Shopify, as we unravel the layers of Ruby infrastructure and the bright future of Rails development. Ufuk's insights into the meticulous work of maintaining CRuby reveal the fine art of balancing performance with modernity while also diving into the exciting realms of TruffleRuby and the Prism compiler. His recent appointment to the Ruby Central board brings a fresh perspective to the community's cherished events, igniting innovative visions for RailsConf that are sure to resonate with enthusiasts and professionals alike.Feel the buzz of RailsConf as we praise the lineup of visionary speakers set to grace the stage, each chosen with the utmost care to embody the conference's core Rails theme. The anticipation bubbles over as we discuss the wealth of knowledge awaiting attendees, from software craftsmanship to the intricate web of professional relationships that flourish within the Rails ecosystem. Get a glimpse of what Hack Days promises, an unparalleled opportunity for real-time collaboration that could very well become the centerpiece of your RailsConf experience.As we gear up for one of the most pivotal gatherings in the Ruby community, we highlight the essential role of Ruby Central—our steward of Ruby's shared resources and the architect of iconic events like RailsConf and RubyConf. The chapter closes with a nod to the potential of supporting local meetups and regional conferences, an endeavor that strengthens the fabric of our community. And for a touch of tech magic, we share tales of Tailscale's impact on developer networking, a pathway to career ascension for many. Stay connected with us online for the latest on RailsConf and more, and prepare to accelerate your professional journey in the world of Ruby.Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.

Today's episode features a detailed discussion about the upcoming RailsConf 2024, itsprogramming, and significant updates in the Ruby community, particularly regardingRuby Central's contributions. Jason, Chris, and Andrew dive into a conversation withguest, Ufuk Kayserilioglu, Engineering Manager at Shopify's Ruby Infrastructure Team,who recently joined the board of Ruby Central and co-chairs RailsConf 2024. Ufukshares insights on the planned enhancements for the conference to make it morepractical and focused on Rails. He also highlights the formation of the Ruby DeveloperExperience team at Shopify, aimed at improving developer experiences within the Rubyecosystem. The conversation further dives into the financial support for Ruby's opensource projects, such as RubyGems.org and the efforts to sustain and secure Ruby'sinfrastructure. The conversation wraps up with details on RailsConf, an open invitationfor community interaction, and a teaser for special experiences awaiting in-personattendees. Press download now to hear more!Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Recently, Ruby Central named a new executive director, Adarsh Pandit. Ruby Central has been a force in the Ruby community for years, organizing conferences and contributing to the community. The recent changes in governance have led t some exciting things on the horizon. Adarsh joined the show to talk about what's going to happen with Ruby Central in 2024. Show Notes Ruby Central Website - https://rubycentral.org/ Ruby Conf Musical Number Video - https://www.youtube.com/watch?v=8WhbX6dS6x0 RubyConf Recap Survey Results - https://rubycentral.org/p/c9897883-2135-4704-b53a-a4111ca272f3/ Ruby Central Get Involved Page - https://rubycentral.org/leadership/ Ruby Central contact page - contact@rubycentral.org RubyConferences.org - https://rubyconferences.org Adarsh's Email - adarsh@rubycentral.org RailsConf Tickets - http://railsconf.org Sam Giddin's Stat of the RubyGems Talk - https://www.youtube.com/watch?v=Hea-x7LHO9Y Announcment of Sam's AWS Security Residency - https://rubycentral.org/news/ruby-central-welcomes-new-software-engineer-in-residence-sponsored-by-aws/ Sponsors Honeybadger (https://www.honeybadger.io/) As an Engineering Manager or an engineer, too much of your time gets sucked up with downtime issues, troubleshooting, and error tracking. How can you spend more time shipping code and less time putting out fires? Honeybadger is how. It's a suite of monitoring tools specifically for devs. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!

In this episode, we jump straight into a candid conversation with Jason, whohumorously contemplates how to kick things off, earning him the title of “recoveringpodcaster” from Chris after a whirlwind month of Ruby discussions without him. We alsohave the charming Andy Croll back, ready to dive into opinions, insights, and personalstories. With RailsConf on the horizon, the conversation brings us to discussing Andy'srole with Ruby Central and his efforts to revitalize the conference experience. As theynavigate through conference planning challenges and the spirit of the community thatdefines the Ruby world, this episode promises a mix of laughter and encouragement forRailsConf attendees, and an enthusiastic invitation from Andy to join what set to be amemorable and engaging event. Press download now to hear more!Honeybadger Honeybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

The conversation covers various aspects of RailsConf, including its mission, organization, and selection process for talks. The chapters delve into the background of the participants, the role of Ruby Central in organizing RailsConf, and the significance of the conference in the Ruby and Rails communities. The discussion also explores the unique features of RailsConf 2024, such as the community day and hack day, as well as the selection process for talks and the responsibilities of the program committee. Additionally, the conversation touches on the criteria for choosing conference locations and the process of selecting keynote speakers. In this conversation, Emmanuel Hayford interviews Andy Croll and Ufuk Kayserilioglu about their experiences with conferences like RailsConf and Brighton Ruby. They discuss the acceptance and rejection process for conference speakers, the origins and purpose of Brighton Ruby, the importance of personal interaction at conferences, the dynamics of partnering with hotels, the sponsorship opportunities for RailsConf, and the benefits of attending conferences for personal and professional growth.TakeawaysRailsConf is a long-running conference that celebrates the Rails framework and brings together the Ruby and Rails communities.Ruby Central plays a crucial role in organizing RailsConf and other Ruby-related projects, maintaining and supporting the Ruby commons that the community depends on.RailsConf 2024 will feature a community day and hack day, providing opportunities for collaboration, learning, and contributing to open source projects.The selection process for talks at RailsConf involves a program committee that ranks and evaluates proposals based on fit, quality, and presentation skills.RailsConf aims to have a diverse range of speakers and topics, with a focus on building with Rails and showcasing different ways of using the framework.The location of RailsConf changes each year, with a focus on accessibility and transportation options for attendees.Keynote speakers at RailsConf are selected based on their relevance to the conference theme and the community's interests.The conference selection process involves a balance of reaching out to potential speakers and reviewing submissions through a call for proposals (CFP). Conference rejections should not be discouraging, as there are limited slots and many applicants. Persistence is key.Brighton Ruby is a single-track, single-day event held in Brighton, UK, that provides a friendly and intimate atmosphere for Ruby and Rails developers.First Ruby Friend is a mentorship program that pairs experienced developers with early-career developers to provide guidance and support.Partnering with hotels allows conferences to secure room blocks for attendees, ensuring convenient and affordable accommodation.Sponsorships for RailsConf offer companies the opportunity to support the Ruby and Rails community while gaining visibility and networking opportunities.Attending conferences like RailsConf and Brighton Ruby provides valuable opportunities for personal and professional growth, including building relationships, gaining insights from talks, and experiencing the sense of community.

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

Welcome to our first ever live episode of Ruby for All, where Andrew and Julie share their vibrant experiences from RubyConf in San Diego. Today, they share their excitement at attending a live conference and their interesting experiences, including their interaction with fellow attendees, sessions they attended, and community building activities they participated in. Also, there's conversations about open source coding, autonomous learning, the future of Ruby, leveraging podcasting within the Ruby community, and their expectations from the rest of the conference. Hit download now to hear more! [00:00:23] Andrew and Julie share their enjoyment of the conference and they discuss their discomfort with team building, with Andrew having a panic attack. [00:02:10] We hear about a new journal app on the iPhone that suggests memories based on places you've visited, and photos taken. [00:02:57] Julie details her experience on the first community day at the Hackspace, where she, Kevin and Drew, explored Ruby LSP (Language Server Protocol), a project from Shopify for better VS Code integration. [00:04:06] Andrew explains Heredocs, and Julie explains they encountered a bug related to a cursor positioning in the code editor while working on a feature for Heredocs.[00:05:46] Julie expresses her appreciation for the hack day format, allowing interaction with project maintainers and suggesting it be included in future conferences. [00:07:50] They give feedback for improving the hack day, such as better signage for project tables and ensuring equal attention venue positively.[00:10:12] The conversation turns to the conference's social aspects, like hanging out by the fire and the arrival of more attendees on Tuesday. They mention Matz's pre-recorded keynote and the opening ceremony. [00:11:24] Julie and Andrew share their thoughts on the opening ceremony.  Andrew clarifies they spoofed “The Wizard of Oz.” Julie notes the performance was unexpected and well-executed. [00:12:38] Andrew mentions that Matz had a pre-recorded keynote, and both Julie and Andrew were disappointed missing the memo that Matz wouldn't be there. Andrew summarizes the keynote mentioning Matz discussing Ruby's future, including Ruby 4.0 expected in 2030, and his plans for retirement. [00:14:00] Julie appreciates how Matz asked first-time conference attendees to raise their hands, demonstrating Ruby's vitality. Andrew and Julie spent time networking in the hallway rather than attending talks, emphasizing the value of personal connections.[00:15:07] They participated in a roundtable discussion about podcasting in the Ruby community that was sponsored by Ruby Central. [00:19:09] Andrew and Julie attended Saron Yitbareks' motivational keynote and Andrew mentions going to a talk on Rack, while Julie preferred hallway networking, planning to watch talk recording later. Panelists:Andrew MasonJulie J.Sponsors:HoneybadgerGoRailsLinks:Andrew Mason X/TwitterAndrew Mason WebsiteJulie J. X/TwitterJulie J. WebsiteHow To Use Heredoc in RubyRuby CentralSaron Yitbarek Rails on Rack (00:23) - Introduction and discomfort with team building (02:10) - New journal app on iPhone (02:57) - Experience on the first community day (04:06) - Heredocs and a bug encountered (05:46) - Appreciation for the hack day format (07:50) - Feedback for improving the hack day (10:12) - Conference's social aspects and opening ceremony (11:24) - Thoughts on the opening ceremony (12:38) - Matz's pre-recorded keynote and Ruby's future (14:00) - Value of personal connections (15:07) - Roundtable discussion about podcasting (19:09) - Attending Saron Yitbarek's keynote and other talks

In this eipsode I had the pleasure of talking to Adarsh Pandit, Executive Director of Ruby Central, who gave me a peek behind the curtain. From discussing his journey through the coding industry to arriving at Ruby Central, to the challenges he tackled stepping into an executive role - Adarsh's story is a tale of perseverance, growth, and community building.Get ready to uncover how Ruby Central is keeping the Ruby community vibrant and innovative. You'll hear about RubyConf and the exciting Community Day initiative that Adarsh is leading - a celebration of knowledge sharing, public speaking, and community engagement. Adarsh also shares his insights on adapting conferences to changing times and the strategies he's using to revamp the RubyTogether membership program. It's a candid look at the realities of running a tech organization in an ever-evolving industry.But we don't stop there. We also dive into Ruby Central's efforts to foster collaboration and creativity within the Ruby community. From fiscal sponsorship programs to the Scholars and Guides Program - Adarsh gives us a detailed tour of how they're stoking the fires of innovation. And not to be missed is our exploration of community building through local meetups. It's all about creating spaces for connections and learning, and we're sure you'll find Adarsh's experiences and insights invaluable. Tune in for a conversation that's not just about code, but also about fostering communities, encouraging creativity, and building a shared sense of purpose in the tech world.Links@adarsh@ruby.social on Mastodonrubycentral.orgRuby Central MembershipsRubyConf 2023Support the showReady to start your own podcast?This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.SponsorsA big thanks to OBLSK for being the very first sponsor of the show!

In this episode, the focus is on RubyConf, the upcoming conference dedicated to the Ruby programming language. They start by talking about the origin and evolution of RubyConf, highlighting its growth in attendance and its impact on the Ruby community. Chelsea details how the conference has adapted to the digital format due to the COVID-19 pandemic but points out the value of in-person connections. They are looking forward to the Community Day event, which will feature various activities to encourage community interaction and an acknowledgment of scholarships that would help more people attend. The event will offer various programming options, workshops, and talks to cater to newcomers and seasoned professionals. There will also be some level of hands-on learning through hacking activities. The conference aims to be inclusive, offering opportunities for mentorship and growth, regardless of one's career stage. Towards the end, the discussion shifts to Ruby Central, the organizing body behind RubyConf and RailsConf. Chelsea and Allison describe multiple avenues for community engagement, ranging from board membership to open-source contributions. They also encourage donations and corporate sponsorships. Don't miss your chance to register for RubyConf and engage with the fantastic Ruby community! RubyConf (https://rubyconf.org/) Follow RubyConf on LinkedIn (https://www.linkedin.com/company/ruby-central-inc/), X (https://twitter.com/rubyconf), YouTube (), or Mastodon (https://ruby.social/@rubyconf). Learn Academy (https://learnacademy.org/) Follow Learn Academy on Facebook (https://www.facebook.com/LEARNSD/), X (https://twitter.com/SDLEARN), LinkedIn (https://www.linkedin.com/school/sd-learn/), or Instagram (https://www.instagram.com/sdlearn/). Follow Chelsea Kaufman on LinkedIn (https://www.linkedin.com/in/chelskaufman/) or X (https://twitter.com/ChelsKaufman). Follow Allison McMillan on LinkedIn (https://www.linkedin.com/in/apmcmillan/) or X (https://twitter.com/allie_p). Visit her website at daydreamsinruby.com (https://daydreamsinruby.com/). Follow thoughtbot on X (https://twitter.com/thoughtbot) or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Allison McMillan and Chelsea Kaufman, Board Directors, and RubyConf '23 Co-chairs. Thank you for joining me. ALLISON: Hi, thanks for having us. CHELSEA: Thanks for having us. VICTORIA: Yes, I'm glad that you were able to make time to come on the show today. I understand, Allison, that you've been having very full weeks with family over the last month. Do you want to tell us a little bit more about that? ALLISON: Yeah, it's...we have just ended what I call the gauntlet of Jewish holidays. But, basically, there are four Jewish holidays starting with Rosh Hashanah, which many folks know that's the Jewish New Year. But what a lot of folks don't know is that there are actually four holidays that are all in a row, each about a week apart. And you do different celebratory things for each of them. And so, it's been really amazing and fun, and lots of, like, sharing our home with others and meals and seeing lots of people. But it is also exhausting. And they basically all fell on weekends this year, which was nice from sort of a scheduling perspective but was exhausting in the fact that I basically have not had a weekend in over a month. So, it was wonderful and tiring. And I am, I guess, both happy and sad that they're over now. VICTORIA: Yeah, that does sound like a lot of quality family time, which has its pros and cons [laughs], right? So, after going through that, do you feel more rested? Or what do you feel like you need to do in order to recuperate and return to your normal energy levels after having every weekend full after that? ALLISON: Oh, that's a great question. I've been looking at my calendar to be like, I should take a day off. I should take a break. I'm working for myself and [inaudible 02:02] entrepreneur consultant. So, I do have the flexibility to do so, but it is hard to look at my calendar and be like, yes, I will take this day off because I deserve it. But, ideally, I would take a day or multiple days off. VICTORIA: Yes. And some of us are lucky enough to have a reason to travel for work purposes and to sneak in a little vacation and be productive [laughs] in our companies. So, I'm curious, Chelsea, if you can tell me a little bit about the option for people to come to San Diego in November and take a restful vacation by the beach and learn a little bit more about Ruby. CHELSEA: Yeah, so RubyConf will be in San Diego this year. As a native San-dieagan, I am a bit biased, but November is a beautiful time to be in San Diego. And we're going to be at the Town and Country, which feels a little bit like we're going to be in a, like, Palm Springs resort. They just went through a major renovation. And there's these really awesome, like, lounge areas with fire pits and just places for people to gather, which really kind of aligns itself with some of the stuff that we're planning because we're really trying to focus in on just connecting Rubyists together. So, to me, it feels like the perfect place because I think San Diego is, one, we're a little bit more low key, a little chill. And it's a great place to just gather and connect and share with people that have, you know, similar interests. VICTORIA: Yes, I live in San Diego now, but I was from Washington, D.C., And I would come and visit my family in San Diego once a year. And they would always go on about how great it is and how beautiful, and everyone is so happy and chill. And I was like, sure, whatever. And then we [chuckles] had the opportunity to move here, and now I'm one of those people who says that [laughs]. Like, it's great, especially in November. Everywhere else is getting a little cold and fall. And San Diego has a little bit of fall, but it's still 75 degrees out. I forget what that is in Celsius. But yes, I'm also super excited. CHELSEA: We have, like, fake fall activities that you can go do. Like, Allison, when you're talking about doing all the family activities and things like that, you know, this is when we start thinking about, oh, we need to go to, like, the pumpkin patch and apple picking and do all these things, but it's not cold or, like, fall weather at all. So, you want to get all, like, bundled up in your cute fall clothes or, like, put my kids and bundle them up in cute things. But then they're, like, sweating and trying to do [laughs] all these funny activities. But I think that there's so many beautiful things to do here that we, like, try and do these, like, fall activities. But then we just end up at the beach and play in the sand [laughs]. VICTORIA: Yeah, I will go out in, like, shorts and a T-shirt because it's that kind of weather. And my neighbors will be wearing full puffy jackets and [laughs], like, long pants and a hat. And they're like, "You're not from around here, are you?" [laughs]. It's like, you guys are silly. But it's fun. Yeah, there's seasons, I think, you know, in November...I made a list of suggested activities for my team members since thoughtbot is sponsoring RubyConf this year. And we're going to have a couple of speakers at the event. And we'll have other thoughtboters available at our booth for people to come up and chat with us. So, I'm really thrilled to be hosting everyone. And I made a list of, like, activities, and most of them were about where to see cool animals [laughs]. I was like, of course, there's the zoo, which is the obvious one, but then there's baby leopard sharks, and there's a season for them. I think they will still be around in November; I'm curious if you know, Chelsea, actually. And then there's, like, the safari parks, and whale watching, and the sea lions at La Jolla and, like, just a bunch of cool animals to see that I think it makes San Diego really special. CHELSEA: I agree. The zoo, the safari park are great places to just hang out and see some really cool exhibits. Balboa Park, the museums there are amazing. Liberty Station is one of my favorite places to go; that it's an old historic naval training center that's been converted into an arts and culture area. So, they have, like, little shops. They have...there's museums. There's brew pubs. There's coffee shops. And then there's beautiful, like, grassy areas, and right by the water, it's one of my favorite places to just go and hang out. ALLISON: This is great. I've done zero research on San Diego so far. So, just, like, I'm writing notes of what things to do and see while I'm there. CHELSEA: Yeah, I know the San Diego Ruby group is trying to put together some, like, local events and things that people can gather and do together. I know that there was a talk about doing a taco crawl. I think if I say that on the podcast, it might actually push them to do it because there are some amazing tacos in San Diego to be had. VICTORIA: Yes, I love that taco crawl. I'll reach out to them because I'll help put something like that together. I'm writing a blog post right now about all of these things and about all the other kind of events that are coming up in San Diego this fall. Great location, great time of year to be here. Tell me a little bit more about RubyConf specifically. And what are you all trying to do different this year than in past events? ALLISON: There are a bunch of things that we're doing differently. Our goal this year with this RubyConf is really to sort of focus on more ways to bring the community together. I think in the last little bit so much excitement around Ruby and Ruby Central and just sort of the community in general. It's a hard time in tech. I think people need to be sort of choosier about sort of what they attend and why they're attending something. And so, we really wanted to help folks connect with each other, help folks get to know other people, help folks sort of reconnect to ways that they love Ruby and the Ruby community and being a Ruby programmer. So, one of the things that we're doing differently is we have a three-day conference. And the way that that sort of broken down is the first day is a Community Day. And the first day is comprised of the workshops, as well as sort of this Hack Day, where people can bring their own projects. We're going to have people there that folks can hack with, sort of open-source projects that folks can work on, all sorts of different stuff. So that people can really sort of get to know one another, work with one another, work with people that they might, you know, admire or have followed in the community for a while, and have that sort of really special experience that doesn't feel as conference-y, right? It feels a little bit more sort of organic in terms of the way that the day will flow and, the options that people have, and sort of what that day looks like. And then following that, we have two days of sort of RubConf with talks and speakers, et cetera. And I'll let Chelsea add anything to Community Day and then also jump into some of the sort of new and different things we're doing at RubyConf. CHELSEA: I agree with Allison in that we've really wanted to focus in on the connection side of things. But I think coming out of the last few years, out of even the last year that's been tough in the industry, just finding ways for people to connect, support, lift up each other, I think that that was something we really wanted to do. And we didn't want it to just be about going and seeing speakers. We wanted to find more ways for people to learn from each other, to connect. And so we added in quite a few of these community connection points. So, on that first day, there's a lot of community aspects to it. We have a lot of learning happening with our workshops and also working on projects, hacking together, showing off what you're working on, connecting with people in the community. It's going to be really focused in on everyone's own skills and talents and coming together and supporting each other in where we're at in our careers, in our learning. And then, the next couple of days will look a little bit familiar in the way that it is structured with some new aspects kind of woven in. We'll have our Community Room, where we're bringing different community groups together so that people can learn more about what is going on in the community, how they can support, how they can connect. And in addition to seeing and learning about some of the new things happening in the Ruby community, we'll also have our Career Pathways room again, which will be a place for people to support their own careers. And that room was really set up so that it wasn't just about early career, but also about folks in their mid and senior careers, and finding the advice, finding the resources, finding the mentorship that they might need in whatever stage of their career that they're at, and figuring out how we can together as a community grow as a whole. VICTORIA: I really appreciate the focus on community. And, for me, as managing director at thoughtbot, in deciding to invest in which conferences we want to attend and sponsor, we find more value in groups that are trying to bring people together around a common passion and purpose versus a particular product. But I'd like to hear from each of you if you can tell me, what does the community mean to you? And I'm looking for, like, a personal story on how you've benefited or how you've engaged with the Ruby community in the past. And what makes you motivated as CEOs and founders of your own companies [laughs] to spend all this time organizing a conference? ALLISON: Many, many, many years ago, I did a Rails Girls workshop. It was actually my first introduction into the tech community, into programming in general. And, for me, really, I did Rails Girls. I did not actually expect to like programming. But I was sort of launching a startup, and I wanted to learn more about tech and blah, blah, blah. And at the end of the day, I was, like, so energized and so excited about what I had built and what I had done. The Ruby community in D.C., who I always think is just a group of really special individuals, was so supportive, was so wonderful, was so, like, "Here's where we co-work on Wednesdays. Come to this coffee shop. Here's how you can keep learning," just was so encouraging. You know, I went to the local Ruby meetup sort of really not knowing anything. And they were excited about, you know, newbies being there and asking questions and, you know, really sort of getting to know folks who are just starting out in their programming journey. And really, through that, I mean, I went to my first RubyConf as a scholar. Was strongly encouraged to do a lightning talk, did a lightning talk. That's how I, you know, sort of ended up having a whole bunch of informational interviews and having conversations with folks. And really, that's how I got my first real job in tech. And so, you know, I want people that are coming into the industry now to have that same support, to have those same opportunities, to have that same encouragement. And, for me, sort of planning RubyConf, planning these conferences, being a part of Ruby Central is really me giving back to the community that has gotten me to where I am today, right? And it's amazing, also, to just...I'm still in touch with the people that were at my table, sort of guiding and mentoring at that first Rails Girls session or the people who I met at the first-ever Ruby meetup that I went to. I still talk to them. I'm still in touch with them. We still get together. I still ask them for, you know, advice and guidance sometimes. And sometimes, they ask me, at this point, for advice and guidance, which is fun. But yeah, it just means so much to me that I have really been able to get to where I'm at because of the support and encouragement of the community. CHELSEA: I have a similar story. I guess over, gosh, over a decade ago, I also went to my first RailsBridge and got introduced to the community there at RailsBridge. And, you know, at the time, I wasn't in tech. I was in the theater. I come from the performing arts. I had spent a very long time executive leadership in the theater. And I got introduced to this community that was so warm and welcoming to people wanting to learn and grow. And I was so interested in how communities are built and how people connect together that I started getting more and more involved in the Ruby community here in San Diego. And just like Allison was saying about the welcoming and warmth that she felt from the D.C. community, I felt the same way here in San Diego. Before that, you know, I had spent so many years being the only woman in a room. I had been in an industry that made me feel like my voice was not always heard. And when I walked into this room, I felt like I mattered. I felt like people wanted to hear what I had to say. And they wanted to learn from my experiences. And in 2014, San Diego hosted RubyConf here. And at that point, my business partner and I launched our business, LEARN Academy, and it's still running strong today. But it was about creating that on-ramp for people and a launchpad into this industry where they could make a difference and they could have their voice heard. And they could be a part of a conversation, even if they hadn't been a part of that community for many, many years, that their background mattered, that their growth mattered. And helping people find their voice at a table is something that is so important to me that I love being able to bring that into the planning of this conference, into a lot of the work that I've done with Ruby Central, with LEARN academy. And really just helping people understand that just because you don't have the traditional background, maybe you didn't start programming at the age of two, you can have a different background and a different path and still provide so much value. And I think that that is the thing that I wanted to continue to be a part of and to make sure was a part of the conversation, that we need so many different types of people at the table. And I want to make sure that our community is responsive to that, that it's inclusive to that, that it's equitable as best we can, and just allows people to share their own experiences. And so, you know, I feel like, for me, we're, you know, almost at our 10-year mark at LEARN academy and that we were launching the company at RubyConf in 2014. To have it here again this year is so special to me. I remember being at the conference many years ago; you know, we spend a lot of time helping companies figure out how to work with early-career developers and to create those pipelines for them so that there's career growth for them. And, you know, I remember sitting around the table and just saying, "Hey, who wants an internship? Who wants to, you know, help these early-career developers?" And everyone raised their hand, and we found some of our very first partners at that conference. And it's always been such a warm and welcoming community that has allowed me to feel like I have a voice and then allows me to help other people find theirs. VICTORIA: Wow, thank you both for sharing that. I totally relate to that feeling of a welcoming community and just getting the sense that, like, wow, everyone who does Ruby is really nice [laughs]. And I think that you know, for me, same as Allison, starting in D.C., there were quite a few people who were involved in Women Who Code who were running Ruby meetups. And that's where I met Valerie Woolard, who I think is also coming to San Diego for RubyConf. I'm excited to see her again. And it's interesting for me coming from that perspective and hearing that from both of you because I've also heard a viewpoint on Ruby community as being highly opinionated and causing certain amounts of consternation. So, I'm curious if you have any comments on that. If not, otherwise, I'm grateful that there are people working to bring that better community in the community that I'm more familiar with more to the forefront and making it more inclusive and open for everyone. So, to, like, bring the question all the way back, it's like [chuckles], do you have any comments on, like, if there's a tendency for Rubyists to be really highly opinionated? Or what else can we do to make it more open and inclusive for people to join the community? CHELSEA: I mean, I think that people are going to be opinionated about something that they care a lot about. And I think that the thing that I've noticed in the Ruby community is people love this language. They love programming in this language, and I think that there's something very powerful about that. And it does, you know, lend itself to people [laughs] having very strong opinions about what they think needs to be out there. And, to me, it's not a matter of, like, whether we have strong opinions or not. It has more to do with whether we're listening or not. But I think it's really important for those of us who are leading to be the listeners, and that we should be there to make sure that there is space for people to be heard, whether their opinion is loud or not. And I think that there are people that are going to be louder than others; that is going to be true no matter where we go. But I think that as long as there is intention around making sure that we are listening to even the quietest voices and that we are creating space for the quietest voices, that's where we're going to find more collaboration. But if we're only going out there and saying, "This is the way it needs to be," and we're not willing to listen to anything else, then I think that growth will stop happening because we need to listen to everyone. We need to be able to create some kind of place for people to come together and share ideas; you know, you don't get the perspectives of all these amazing people in the industry. So, that's why I feel like, you know, I've been on the board at Ruby Central for about a year now, and the biggest thing that I feel like I can contribute is to simply listen. If I can help in any way of filtering ideas or creating connections with people because I've been putting my ear to the ground and saying, "Okay, these people are talking about this, and we're expanding here." And we just want to make sure that we're doing the best we can at being open to all different kinds of ideas and not closing anyone off. Maybe your opinion is really strong. It doesn't mean that we should shut you down. It just means that we need to make sure that there's space for other people, too. And I think that that's the part that, you know, as someone who has always been a bit of an introvert, a bit of a wallflower, I understand how hard it is to get my voice out there. And so, I often fight for the quiet people. I think in every language and any space where it's a craft, it's something that we're creating, people get really passionate about it. And that's going to happen. And I think there's something powerful in that because there's going to be change that happens from that. But if we're not doing our part in the listening and making sure that there isn't just one voice, that there's a collective voice, that's the part that I felt so powerful when I joined the community so many years ago was that, even though I had, you know, months of experience, my questions mattered. And as long as we hold on to that, the community will continue to grow. But those of us at Ruby Central and some of the other organizations, if we're creating space to allow people to question, allow people to speak their opinions and listen, then I think that the industry, the community will just continue to thrive because of that. But we have to be open, and we have to be compassionate when we're doing our listening. ALLISON: Yeah, I agree with all of that. And I would just add in safe places, in a way that we're creating sort of safe structures and safe places for folks to communicate. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it's easy for spending creep to sneak in when your team isn't looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. VICTORIA: What, if you could tell me, what does Ruby really have going for it? Like what makes Ruby a good choice for tech founders or for new companies would make someone decide they want to build with Ruby? ALLISON: First, it's a little bit about just sort of the ease of the language to jump into and to understand, right? There's a lot that you can get done very quickly with Ruby and Rails. And in addition to sort of individuals being able to work in it, there's a whole community of resources, and support, and podcasts, and tutorials, and all sorts of stuff. I know that as an engineering leader at any company, when engineers are coming to me with, like, the desire to use a new language or try something new, part of what I look at is, if I'm going to hire, like, what would hiring look like? What does it look like for engineers to have to ramp up in this area? How long does that take? What resources are available? What sort of community am I pulling from and looking at? And that's both community in terms of sort of technical experience, expertise, years, et cetera, but also non-technical skills, right? What does the community look like in terms of some of those ideals around communication, collaboration, just sort of general pieces like that? And so, I think that, given sort of the strength of open source, strength of community, community contributions, ways to contribute, etcetera, I think that's one of the reasons that it still makes Ruby a really strong choice for folks to build in and to work with. VICTORIA: What type of people, what personas do you think will be the most interested in attending RubyConf? Is it all just going to be, like, senior or super Ruby developers, or what? CHELSEA: Oh, I don't think so. I mean, this RubyConf, in particular, is great for anyone on a learning journey. We've worked really hard to make sure there's a good breadth of programming for different folks in different stages of their careers. I think that, you know, those of you that are maybe earlier on there, this is a great opportunity to meet people who are maybe even a step or two ahead of you. I think that the best mentorship that you can find is someone who is only maybe a year ahead of you because they're going to recognize where you're at and help you along the way. And I think that there's a lot of opportunities here for that. I think that with our Community Day, the hacking that's going to be involved, like, maybe, as a new developer, you wouldn't be able to come in and, like, get your hands really dirty. But you'll get to sit next to somebody who has been through all the different stages and get to watch, and explore, and learn. I think that making those connections could be really great for anyone's career. I think that our mid-level developers, folks that are our management, there's great resources for them to connect with other developers in similar stages. There's great workshops. Because of our focus on the community, I think that it's going to be a place where you can really connect with other Rubyists. And so, if you are at a stage in your career that you want to figure out what that next spring is, where that next ladder step is, this is a good place to see all the different options because you're going to be surrounded by people in all different stages of their careers. And what we've, I think, said now quite a few times is so many people there are just so excited to help people continue that growth. And so, I think that no matter what stage you're in, you're going to find people there that are excited to help you along the way. That being said, I think for our more senior, more advanced, our executive leadership, this is going to be a great place to, one, meet some really great talent, and, two, I think, learn from other folks in the industry of, like, where people are at, what we're struggling with, and how we're changing and doing things differently. So, I really do think there's going to be a little bit of everything for people. And what I love about that is really that it gets to the core and heart of the Ruby community because we're so excited about new folks coming in that that growth continues, that you have folks like Allison who started out as a scholar and want to give back. And then because we have folks at all those different stages, you can find people that are, you know, maybe a step or two ahead of you that are going to be able to help bring you up to that next level. So, I think it's an exciting opportunity for people to really meet new people, learn some new things, maybe find a little bit of encouragement, empowerment on where you're going to go next on your career. VICTORIA: Yeah, absolutely. And it reminds me of an article I read while I was at RailsConf earlier this year about why we do conferences and what's the whole point. And, you know, for me, all of those things are true, like, all those values. As an executive, I'm going to meet a lot of great talent. I'm going to connect with other companies. I'm just going to get to show up and say hi to people and ask them questions in a way that's very informal. And that's so valuable to have that. I think where I was going to go next with this was with Ruby Central, which I believe organizes both RailsConf and RubyConf. (And you can correct me if I'm wrong on that.) I'm curious if there are anything else you want to talk about with, like how the community can engage in support and how other companies could get involved with the community and show their support. CHELSEA: I think that there's quite a few different ways for folks to get involved. We are currently recruiting board members. We just finished a round just now. But I know that in our planning, that we're likely going to bring on at least one, maybe two more, in the next six months. So, I definitely...for folks in the community that want to get involved, that is a really great place to really get involved with Ruby Central. We also have a really strong open-source community. And we're working, oh gosh, with quite a few different companies now that are really helping to support our open-source efforts. And those are also good ways to get involved. You know, we do plan both RailsConf and RubyConf. RailsConf will be in the spring again. And, you know, it takes a village to put on a conference like this and that, you know, we also look for programming committee members to help us shape the program of the conferences. So, if you are interested in any of that, that's also another great way to get involved in the community. We have an amazing programming committee that's helped us with RubyConf. And I'm excited to see what we do next with RailsConf. And I think that you know if you're one that's going to the conference and are saying, "Man, I wish that they would do this," or "I wish I could see that," come and talk to us because that's the best way for us to learn, that we want to hear all of those pieces. But don't be surprised if we then send you an email and say, "Hey, you want to be on our programming committee with us?" ALLISON: I'll add that we also, through our website, we take donations. So, if you want to help monetarily, there's the option to do that on the website. And if you're a company, I mean, we're always looking for conference sponsorships. But if your company also is interested in getting involved in sort of more of a corporate sense of sponsoring or supporting Ruby Central, we are always open to those conversations. You can send an email to contact@rubycentral.org. VICTORIA: That's great. I have a fun question about the conference because I'm leading the event with thoughtbot since I live here. And I'm thinking about some fun swag to give away. Rank your preferences on what kind of swag you'd like to see at the thoughtbot sponsor booth: a thoughtbot-branded surfboard or, a boogie board, a bucket hat, or a pickleball paddle. Any of those interesting for you? ALLISON: Wait, when you say surfboard, like, how am I going to get a surfboard back to D.C.? [laughter] VICTORIA: Okay. I think it's, like, kind of funny because if you win it, it's like, well, what do you do? [laughter] You got to shake it back. That sounds like maybe a boogie board. CHELSEA: Yeah, I'm down for a boogie board. VICTORIA: Thank you so [laughs] much for entertaining me on that one. Is there anything else that you would like to promote today? ALLISON: We would love to see everybody at RubyConf. You can register. Check out the program speakers, et cetera, at rubyconf.org. You can learn more about Ruby Central at rubycentral.org. Those are, I think, the two things that we'd love to make sure everybody knows about. CHELSEA: And if you're here in San Diego, come say hello. VICTORIA: Yes, I have met up with a few random people from the internet [laughs] who have said like, "I'm in San Diego. Who should I say hi [inaudible 34:02]?" I was like, "Me, me, me," [laughter]. So, yes, I'm very happy to meet up for drinks. Chelsea, you and I will have to get together sometime soon before the conference. And I'm super excited for RubyConf. And thank you both so much for being here today. ALLISON: Thanks for having us. CHELSEA: Thank you. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantsrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. 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. Special Guests: Allison McMillan and Chelsea Kaufman.

Ruby Central's Adarsh Pandit and Allison McMillan join the show to discuss Ruby Central, how organizing conferences has changed in the past few years, and more.Ruby CentralRubyConf — Buy your ticket now.Follow us on Mastodon: Rooftop Ruby Collin Joel Show art created by JD Davis.

Special co-host Kevin Murphy joined Brittany this week to interview Allison McMillan and Chelsea Kaufman, co-chairs of the upcoming Rubyconf 2023 happening in San Diego. The quartet discussed lessons learned from Railsconf 2023, the approach to thinking about and planning this year's Rubyconf and what is new and different at the event. Show Notes: Buy Tickets to Rubyconf 2023 (https://rubyconf.org/register) Ruby Central (https://rubycentral.org/) Allison McMillan's website (https://daydreamsinruby.com/) Chelsea Kaufman on LinkedIn (https://www.linkedin.com/in/chelskaufman/) Kevin Murphy's website (https://kevinjmurphy.com/) Sponsored By: Honeybadger (https://www.honeybadger.io/) If you want to simplify your stack, and lower your bills, it's time to check out Honeybager. Honeybadger combines all of those services into one easy to use platform—it's everything you need to keep production healthy and your customers happy. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free!

Ruby Central head of open source André Arko talks Bundler, Ruby Gems, supporting the community, and more.André Arko will be speaking at RubyConf 2023 this year Support Bundler/RubyGems open source work via Ruby CentralFollow us on Mastodon: Rooftop Ruby Collin Joel Show art created by JD Davis.

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.

On this episode of Remote Ruby, the guys discuss various topics relating to hosting options, web frameworks, open source projects, and give us a recap on RailsConf 2023.  They dive into the pros and cons of serverless architectures like Lambda, Jason's experience with Roda, their interests in front-end technologies and JavaScript integration in Rails, and Andrew tells us about regex for playground. We'll hear their thoughts on RailsConf, their favorite talks, Chris's workshop, things that could have been better, and the importance of community contributions, transparency, and the need for clearer communication. Also, if you missed this RailsConf, they mention some other conferences coming up, so hit download to hear more![00:00:10] Chris brings up the blog post on Amazon's AWS blog which sparks a discussion about the effectiveness of serverless architectures like Lambda. [00:02:02] The conversation shifts to Jason telling us his experience with building a microservice using Roda. Then he tells us the benefits of Roda and compared it to Sinatra, and now Andrew wants to upgrade his Sinatra app to Roda since Jason had such a positive experience.[00:05:48] Cloudflare Workers, Puppeteer, Rust and JavaScript are discussed. [00:09:06] Chris shares his thoughts on RailsConf, mentioning attendance was smaller than expected. The guys also bring up that there was no hallway track and the spread out nature of the event, which made it less conducive to casual networking and impromptu conversations. Chris enjoyed the keynotes and attending a talk by Jordan Burke on hosting with Hatchbox, Fly , and Render. [00:12:10] There's a conversation on the need for more direction and talks on front-end technologies and JavaScript integration in Rails, and where to go if you want to learn more about these topics and contribute to the community. [00:14:26] Chris shares his takeaway from RailsConf, mentioning his interest in reading Rails commits daily to stay up to date with the community's progress. He also talks about his favorite part of the conference was an encounter with a Lightning Talk presenter who worked on the same project he did 13 years ago.  [00:17:16] Jumpstart Pro has been updated to Rails 7.1 and we hear the changes, and the conversation shifts to regex and a tool Andrew finds useful called “iHateRegex” and “regex for playground” that helps visualize regular expressions. [00:21:19] At RailsConf, Chris gave his first ever workshop with Colin Loretz. The talk focused on Webhooks and their handling in Rails and Chris made a screencast of the workshop and integrated the code into Jumpstart Pro.[00:26:06] Chris and Andrew talk about needing more scholars and promotions for the guide program at RailsConf. Also, they liked how there was a huge emphasis on Junior developers this year.  [00:29:03] Ruby Central is talked about and how more clarity regarding how community contributions are used, and they mention the change in leadership within Ruby Central and the impact it has had on the community. [00:38:24] The guys talk about all the upcoming conferences, including RailsConf and RubyConf. and Andrew shares his experience with social anxiety during the conference.[00:43:25] Chris mentions a hearing a rumor about Rails 7.1 shipping very soon, and Andrew tells us Jason dunked on him at RailsConf in front of everybody. [00:46:49] We end with the guys expressing their gratitude to the organizers and sponsors of RailsConf and encourage juniors to attend conferences to find job opportunities. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterRuby Conferences 2023Even Amazon can't make sense of serverless or microservices by David Heinemeier HanssonRodaCloudflare WorkersPuppeteerRustThis Week in Railsregex for playgroundHow to Process Inbound Webhooks (RailsConf 2023)-GoRailsRuby CentralRuby Radar TwitterRuby for All Podcast

Joël and Drew join Brittany post-conference to discuss their experience at Railsconf 2023 in Atlanta, Georgia. The trio thank the organizers, share tales from speaking and discuss their favorite talks. They wrap by discussing the new Ruby Central individual memberships and their conference plans for the rest of the year. Show Notes: The Bikeshed (https://www.bikeshed.fm/) Code and the Coding Coders who Code it (https://podcast.drbragg.dev/) Railsconf (https://railsconf.org/) In Favor of Ruby Central Memberships (https://dev.to/baweaver/in-favor-of-ruby-central-memberships-15gl) Sponsored By: Honeybadger (https://www.honeybadger.io/) If you want to simplify your stack, and lower your bills, it's time to check out Honeybager. Honeybadger combines all of those services into one easy to use platform—it's everything you need to keep production healthy and your customers happy. Get started today in as little as 5 minutes at Honeybadger.io (https://www.honeybadger.io/) with plans starting at free! Mirror Placement (https://www.mirrorplacement.com/) Mirror Placement are the Ruby on Rails & JavaScript recruiters. They are actively engaged with a wide and deep network of Rails, JavaScript, and Full-Stack Open Source engineers and tech leaders we love, with relationships cultivated over 15 years. Contact Brian, co-host of this podcast, here (https://www.mirrorplacement.com/contact).

For this week's episode, Aji & Mina read chapters 8 through 13 of "Getting Started with Rails". They discussed RailsConf and Ruby Central, refactoring using concerns and partials, semantic HTML, and much more.Reading for this episode: Chapters 8-13 in "Getting Started with Rails"Ruby Central (Hit SIGN IN, then SIGN UP)Brittany Martin & the Ruby on Rails PodcastDrew Bragg & Code and the Coding Coders who Code itMDN : The Anchor elementReading for Episode 4: "Active Record Basics"

Joël is a mentor for RailsConf and got matched with a speaker. Stephanie has been having trouble stepping away from her work. It's frustrating when chasing down a bug because something's gone wrong, and you spend a whole afternoon figuring out where it is. Joël and Stephanie discuss error handling as a possible solution. 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. Mis en Place Writing (https://www.swyx.io/writing-mise-en-place) Errors accumulate at boundaries (https://thoughtbot.com/blog/testing-your-edge-cases) Retryable errors (https://thoughtbot.com/blog/handling-errors-when-working-with-external-apis) Transcript: STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn. JOËL: And I'm Joël Quenneville. And together, we're here to share a bit of what we've learned along the way. STEPHANIE: So, Joël, what's new in your world? JOËL: So recently, RailsConf has closed out their CFP, and they've started sending out acceptances and rejections for proposals. And one thing that they do that I think is really nice is that they offer first-time speakers the ability to get matched with a speaker-mentor, somebody else who has given talks before that can help them prep their talk, listen to them rehearse, that kind of thing. And so they had put out a call for mentors last week. I responded to that, and I got matched with a speaker today. STEPHANIE: Cool. Is this your first time being a speaker-mentor? JOËL: First time for RailsConf. I've done it for another conference before. STEPHANIE: That's really exciting. What do you like about playing that role? JOËL: So I very much like prepping and giving talks myself. And I really value if there's something that I'm excited about sharing it, helping others build up that skill as well. So I think it's a great opportunity. I also remember what it was like when I was a first-time speaker and just how very nervous I was and not sure. So I think having someone who can play that role is an opportunity to have a really powerful impact in what's oftentimes, I want to say, a monumental moment. But it's kind of like a milestone marker moment in someone's career, the first time I gave a talk at a conference. So you get to help them to make that moment the best it can be. STEPHANIE: I love that, yeah. You make a really great point that after you've been speaking for a while, you maybe might forget what it felt like to give your first talk and how big of a deal it is. And in general, I think one thing I really love about Ruby Central conferences is how supportive they are of first-time speakers. So even in the CFP, they mentioned that they welcome first-time speakers and want to make sure to accept talks from those folks and then provide them support through this mentor program. And yeah, it just makes me feel really happy. JOËL: Do you remember your first talk? STEPHANIE: I do. So my very first talk I gave virtually at RubyConf in 2021. And then last year was actually my first in-person talk. And I remember even though it was technically my second talk; it was really my first talk in front of an audience. And I saw speakers in the Slack workspace asking questions about the AV setup, and I didn't even think to consider that in my preparation. So it was nice. Even though I didn't get set up with a mentor, to share a space with other experienced speakers and see what kinds of things they were asking about or what kinds of things they were sharing in that Slack space was helpful for me. JOËL: So when you do a proposal, do you typically have an outline already built out, or is it mostly a concept that you're pitching, and then you maybe start with an outline? Or where do you go next after a proposal has been accepted? STEPHANIE: That's a great question. I think first, I procrastinate for several months, [laughs], but I do try to write an outline in the proposal when I submit it so I do have a starting point. And I think that actually helps the CFP committee, too, when they are evaluating proposals to kind of get a better idea of what the talk will be about. And so, in my ideal world, I already have some structure, so by the time I've procrastinated to the point where it's a month or so before the conference itself, [laughs] I have an outline. And I end up writing words, like, I will just write my talk as if it were an essay with this bullet point outline already. And I find that helpful for me because I definitely have a bit of a stream-of-consciousness productivity energy. And so if I just put it all out there, I will then go back and be very ruthless, I suppose, in my editing, and I think that's where the magic happens. So I kind of let myself just word vomit all over the page. And then the real work comes in the editing process and organizing and making sure it sounds the way I would want it to sound when I'm speaking. And yeah, that's how it has worked for me so far. JOËL: So you have a sort of a separate phase for sort of just stream of consciousness dumping and then separately editing. And having those two separate is an important part of your process. STEPHANIE: Yeah, I think so. I don't do as well trying to imagine the structure and everything perfectly the first time around and then filling things in. I find that just putting everything out there and, you know, a lot of things get cut. But that works well for me. What about you? What is your typical conference talk writing process? JOËL: I think mine is a little bit more iterative. I tend to put in some pieces that I like and then try to connect them together, try to make sure it's telling a story. I think a lot about the pedagogical side of things, where people are going to be confused, where they're going to have questions, where they might check out. And then very early, start doing kind of draft rehearsals where I'm starting to work on the talk. And I will stop halfway through because, in my mind, I'm trying to seat myself in the audience and be a person who's listening. And there might be a moment where I'm like, wait a minute, you just jump from one thing to another, and I don't get the logical connection here. And I might pause right there in the rehearsal and add in, say, okay, we need a transitional point, or we need to explain a concept between these two. And I keep doing that until I can get through the whole thing and then realize it's way too long and start cutting. And I cut aggressively, and now it's too short. And now I go through it again. And again, people have questions in the audience, hypothetical audience; I am the audience. And so I really kind of inflate it and then cut it down and re-inflate it and cut it down a bunch of times until I'm happy. STEPHANIE: I like that a lot. That sounds right. That sounds very you to work even on a conference talk iteratively. JOËL: It's very time-consuming. So I don't know it's the most efficient way to build a talk, but it's a process that works for me. STEPHANIE: Yeah, that's true. And then there's value in the journey, even if the talk ends up changing from the very beginning to the end product. JOËL: So the approach that you described for yourself, I think, where you have a rough draft, and you're separating the editing from almost like a creative process, reminds me a lot of an article that I read called "Mise en Place Writing" by...I'm not sure what their full name is. They go by the handle Swyx. This is an article about their process for writing, but I think it applies to conference talks as well. Have you seen this article? STEPHANIE: I haven't. But that, I think, is similar to how I've thought about it or I've seen or heard other authors talk about their writing process and it being kind of similar where the creative work...they give themselves a lot of grace and just letting it be. And then the, like I mentioned, real work is in the editing process. It's kind of two different mindsets, I think. JOËL: We'll link the article in the show notes. STEPHANIE: I'm curious then how you incorporate visuals into your process because I think that's where my workflow is a little less successful because I'm not really thinking about visuals along with the words, and they do feel more like an afterthought. And I've always been really impressed when people who give talks can have a really visual and dynamic slide presentation. How does that work for you? JOËL: So I think I try to avoid slides that are three bullet points in the slide, and then I'm going to talk about it for three or four minutes for each bullet point. People read those quickly and then check out. I'll oftentimes try to have, like, turn each of those bullet points into a full-on slide. And maybe it's just a title and a fun picture or something like that. What this ends up doing is I kind of really inflate my slide deck. I'm going through maybe 80 or 100 slides in a 30-minute presentation. So it's multiple slides a minute. They move by really quickly. So I usually have either just an image or a header. I will usually start by just sketching it out with headers and then, where it makes sense, using an image. An image can be just for fun, or it can be something like a diagram where it is trying to illustrate a point. STEPHANIE: Yeah, I like that. I think talks with a lot of slides that are mostly just images or something that you can grasp in a few seconds are really engaging because you're keeping it moving, and you don't really let people get bored. And so you show a new slide, and they look at it, but then they are able to direct their attention back to what you're saying. JOËL: It's fun too with images because you can reuse them, and then they become a way to connect people back to a theme or let them know that you're making the same point again. A lot of talks, I will have a central theme that gets repeated. I'll often have a slide with some fun image with my key point on it. And then that slide will show up three or four times in my presentation oftentimes because each of the main points I'm trying to make kind of culminates at that same takeaway. And so for example, in the talk I gave at RubyConf Mini last fall, I had a slide about writing Ruby code being delightful. I think having some children being happy with just a big title being like, "Oh, delightful," or something like that. And after each of my examples where we went from code that was less good to something that was more idiomatic, Ruby that was really fun to work with, I would finish on that slide and be like, hey, our code is now delightful. And hopefully, that helped people with the takeaway of, like, we want to write delightful code. Ruby has tools to do that. And then, hopefully, they either remember the things they can do to get to that point or can look it up and find a talk online. STEPHANIE: Yeah, I watched that talk, and I really vividly remember that slide and the theme that you were trying to hone in on. So I thought it was pretty effective. I think this makes me realize speaking, I mean; speaking is obviously a skill but even the process of creating a talk in that particular medium is also a vast skill and can go...there are so many different styles and flavors. But I really think that what you said will get me thinking next time I'm writing my talk and how I can better incorporate that kind of engagement with the audience and making sure that the way I deliver the talk is just as thoughtful as the content itself. JOËL: Yeah, I've been putting a lot of thought into what makes a good talk and what elements are unique to my process, what elements can be useful to others because now I have to coach someone else on their process and say, "Hey, here's the thing that worked for me. Maybe this will be helpful for you." Or maybe it's just, "Have you tried this?" Or "I think audiences will be asking this question at this moment, what do you think of this?" So that's definitely been top of mind in a whole other dimension for me recently. How about you? What's new in your world? STEPHANIE: So before we started recording, I was heads down deep in the muck of trying to write some tests, some RSpec tests on my client project. And the domain for this client project is really big. There are a lot of models. And I was starting to go deep into the factory setups for our test fixtures. And it was hairy. And I was just going further and further down the rabbit hole to the point where I was skipping lunch. JOËL: Ooooh. STEPHANIE: Yeah, I was like, I couldn't pull myself away from it, and I kind of regret it a little bit. [laughs] And so I was just thinking about, like, how can I incorporate taking breaks a little bit more and feeling better about stepping away from the work when I'm really deep in it? You and I had this standing appointment to record [laughs] a podcast, so that was kind of the signal to me that it was time to try to set it aside. And I did end up taking the dog for a walk around the block beforehand to get some fresh air, but yeah, it was a little rough, I don't know. How do you deal with just being so deep in the code that you don't really want to resurface? JOËL: That's hard because sometimes I'm feeling productive, and I don't want to stop because I feel like I might not get back into the flow quite as easily. Sometimes it's just out of frustration. It's like, oh, I'm just so close to getting this bug done. If I get this one more test to pass, then I'll be good. And I keep doing one more thing. And the next thing I know, I have skipped lunch, and it's late in the afternoon. And it's just like; it's been a frustrating day. STEPHANIE: And you're cranky, yeah, yep. I know that feeling. JOËL: I've stopped being productive for the past hour. But I'll be like, one more thing, one more thing. STEPHANIE: I think I was in that place because I was starting to get deep into the internals of models completely unrelated to the test that I was writing, but that was just where the rabbit hole led me. And I think after this, I will go and ask in Slack for a pair because I think that would be really helpful right now. I've just reached the limits of what I know. And I'm almost positive that someone knows how to do this more efficiently than I do. So that was a bit of a signal to me, but it was very challenging untangling myself out of that headspace. JOËL: Have you ever played the video game Civilization? STEPHANIE: No, I haven't. JOËL: It's a turn-based historical strategy game. The running joke about it is that people get really pulled into it. And they're always just saying, "I'm going to play one more turn, and then I'm going to be done for the evening." And the next thing you know, it's 4:00 a.m. And I think that sometimes applies to fixing one more failure, just getting one more file in that chain of figuring out what the bug is in code. It's a very similar feeling. STEPHANIE: Yeah, I know exactly what you're talking about. 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 it can be really frustrating when you're kind of chasing down a bug because something's gone wrong, and now you're spending a whole afternoon figuring out where it is. Do you ever find yourself maybe acting preemptively to try to prevent those sorts of things from happening in the first place? So maybe putting in some sort of guards or error handling or something like that so that your future self won't have to spend that afternoon. STEPHANIE: That's a great point because the bug that I was facing just now was definitely something I think could have been avoided. It was a classic no method [laughs] on nil class error. And I am still unsure how that happened, and I hope to come back to it after this. But yeah, that certainly is a great topic to get into, error handling. I think it's been on my mind a little bit lately because I'm working on a full-stack feature that has user-facing errors and things we want to make sure that we communicate to the user so that they could hopefully do something about it or just contact customer support on this app. But there are also some API calls that are kicked off in the process of the user submitting the form, and those can lead to a bunch of different failures. And we may or may not have already discovered what those failures could be, and there may or may not have been designs created for those different failure states. And I feel like I haven't quite gotten a handle on how to deal with all of the possible errors that can happen when implementing a full-stack feature or a vertical slice. Yeah, that has tripped me up a lot lately. JOËL: I think my time working in Elm has really made me much more aware of the different ways that things can fail just because Elm's type system is very robust. It's very complete. And so it will point out to you every potential place that could have a failure and ask you to handle it because it doesn't want to get to a point where it doesn't know what to do and there's a runtime error for something like no method or something like that. So if you've got a potential nullable value and you're trying to say, okay, take this and render it, the compiler will say, wait a minute, you did not handle the null case. Give me something to do with the null case, or I refuse to compile. And now you've got to handle that. If there's something that might feel like an HTTP request, again, the compiler would be like, well, but what about the failure case? You didn't tell me what to do on the failure case. This is an incomplete piece of code. I refuse to compile that. So I think I've built now a little bit of anticipation because I know the compiler is going to tell me to do this. Now even when I write code that's not compiled like Ruby, my brain compiler is still like, oh, there's a nullable value here. You didn't check the null case. What are you going to do about that? STEPHANIE: Yeah, that's a great point. I think the more experience I gain, the more possible errors I see in the world or out in the wild. When I think about developing on the web, you know, you mentioned HTTP requests, but also, if we fail to connect to the database or a job fails to enqueue, there are just so many places where things can go wrong. And it's almost like the more I learn about all those possible failures, the more anxious I am [laughs] to make sure that I've covered everything though I think there is some amount of just that being impossible. And I'm particularly interested in figuring out what is enough because one thing that really I find quite painful is when you don't think through things enough and you just cross your fingers and hope it works and you ship it, and then your team is dealing with a lot of bugs or a lot of noisy error monitoring notifications afterwards. And so that's kind of what I'm trying to adjust for, I think. JOËL: I think there's like two general classes of approach you can use to deal with that; one is to try to prevent errors altogether, and there's a variety of tools you could use for that. I'm thinking of either something like a type system or maybe test-driven development or even some sort of analysis tool. That could be diagramming, that could be decision tables, something like that. All those, I think, fall under better understanding of the edges of your system. Whereas sometimes you want to do the opposite and sort of really lean into, okay, errors will happen. How do we recover from them? How do we make them easy to diagnose in the future? STEPHANIE: Yeah, that second bit is really interesting to me because I've started to try to think about the errors and who we want to notify about the errors. And so I feel like there are a few different categories of errors where if it's a validation error and it's something that the user can fix, you know, that we want to make sure to surface and tell them how they can fix it. If it's like a programming error, there's no value in showing that to the user. And I'm sure that we've all seen a website that responded with a 500, but then we actually saw the error message itself, and we're like, ooh, this is kind of weird [laughs] to be seeing this. And so realizing, okay, that's not valuable to the user. But what should I be doing with it instead? And maybe that is hooking it up to whatever error monitoring service you use to make sure someone is alerted. Or, I don't know, even in the third case, like, what should a customer support team be notified about? And that kind of sits in between not quite a user-facing error but also not a bug, and that's a different category. JOËL: So, something that is not necessarily a problem in the code, but you might want somebody in the company to know about and be notified about. STEPHANIE: Yeah, exactly. Maybe not something that is so urgent that it needs to be flagged in real-time but goes somewhere, and someone will check on it at some point. [laughs] So you were mentioning that you now have a better sense of what could go wrong. How much time do you spend writing code to cover all of those different possibilities? JOËL: Hmm, I don't know that I've ever put the time to quantify it. I would say a decent amount because you've got to think about...sometimes they're not even things that can go wrong per se. But they're off that very simple, linear happy path that you're thinking of. So you might think even for rendering some kind of view, and you've got some search results you're trying to display. Have you considered an empty state? Is there a difference between initially loading the page or have not performed a search yet, and search but did not find any results? Those are things that are not necessarily errors, but they're not things you're thinking in mind when you're just writing that first happy path of, like, oh, load page, show results. I assume there's always a result set. And so those are things that are important for the user experience that you need to have, but that are kind of edge cases that you have to add in afterwards, or you have to think about. And so I think that, for me, tends to fall under a similar category as okay; what if an error happened? Especially when you're dealing with kind of a full-stack situation where on the front end maybe you're making a result to a back end to pull down...let's say you're making a search and the back end is doing the actual search. You send up a query. Now you get back a failure. Is that the same thing as getting no results back? Like, a success with no results, versus an error code, versus not making a query yet. So you've got like four or five states you've got to think about on the front end to display and how you're going to handle those. So I think thinking about those upfront is often really helpful. STEPHANIE: As you were talking about that, I suppose I asked the question because I have experienced when those things are not thought about upfront, and then you discover them as you're implementing. And how much time do you use to kind of go into a little detouring trying to make sure that you have all of the edge cases covered, and at what point do you stop? Because you're like, I've covered what I can. And this ticket was supposed to only be three points [laughs] or whatever, you know. JOËL: Yeah. And how do you keep a feature from ballooning when there are all these edge cases? STEPHANIE: Yeah, exactly. It's a balance. JOËL: Are there any techniques that you like to do when you...so you pick up a ticket that looks easy, but that might have a lot of these hidden edge cases in it. Are there techniques you like to use that might help you figure out those edge cases and maybe give you some follow-up questions that you might reach out to the product person to clarify? Or maybe it's mostly intuition and experience as a developer that you kind of figure out that, oh, these are the things we need to ask about. It's like, have you thought about an error state? STEPHANIE: Yeah, that's a good question. In general, I'm a little suspicious of any ticket that doesn't include some kind of acceptance criteria about the unhappy path. And I certainly think it's a lot easier once you are embedded into this domain, and you have that expertise, and you are able to see the possible issues you'll run into. I do think that I like to do a little bit of coding just to kind of explore the space, and then that does give me more insight into how I might be able to follow up on the ticket. So you mentioned techniques. Especially if they're written as user stories, I don't think they necessarily incorporate the flow or the procedure of how things are kicked off. And so when you're thinking about implementing it, you're like, oh, this actually needs to happen in the background, or this should be synchronous or not. And those are a lot of error states that I find are missing when I pick up a ticket. And I think it also depends on which way you want to implement it what implementation is viable. And then maybe you bring it to a product person, and they are actually like, "No, we don't want it to work like that." And then you have to kind of rethink things a little bit. But yeah, certainly, the process of taking a user story and then doing an initial think-through of what approach you want to take definitely surfaces some potential unhappy paths. JOËL: It's almost like prototyping it in your mind. STEPHANIE: Yeah, I think so. I think it also depends a little bit on the team because if the engineer wrote the ticket, then there likely has been some thought about unhappy paths. But on other teams that I've been on when implementation is up to the person who picked it up rather than kind of spelled out for you by someone else who did that thinking, that's definitely an opportunity to pause, I think, and document which way you might want to go so that you can make sure that you account for the possible things that could go wrong that likely the user story didn't cover. JOËL: Sometimes there are some edge cases or failure states that are just sort of built into the problem that you're solving. If you're having to make a background request, there's always a chance that that might fail because the network is not trustworthy. Sometimes though, those things just kind of come out of our implementation, the fact that we implemented it in a particular way. And that's not something that you'd expect a product person to have to think about. That's more on us as developers to be like, oh yeah, well, I'm indexing into a hash and didn't think to check is a nested hash even present? Maybe that key isn't there. And now I've got a weird nil error, an undefined method. That's kind of on us rather than on, like, oh, a specific kind of thing that we can think about upfront. STEPHANIE: Yeah, that's fair. And I think that is just an important part of the development process. Though you make a good point because I think that just kind of speaks to all of the different layers of things that can go wrong [laughs] and figuring out which ones are specific to your role as developer to account for, and then which are ones that you need to bring in or pull in a designer to chat about. It can be a little overwhelming. I'm overwhelmed just thinking about it. [laughter] JOËL: Yeah, errors are not a sort of monolithic class of things. They can't be an afterthought. But they're also not just a thing where it's like, oh yeah, do the error handling, and then you're good. We kind of lump a lot of things under the concept of errors, even if they might all eventually manifest as some kind of exception. I guess a true solution is just one giant top-level rescue nil. STEPHANIE: [laughs] Very funny. JOËL: So we've talked about a few different dimensions of errors where they might be sort of user-visible or not, or something that's more implementation-based versus inherent to the problem. One thing that we haven't looked at is the dimension of errors that might be recoverable versus not. Have you ever built a system where you had errors that could be recovered from and didn't crash the program? STEPHANIE: Ooh, yes. That makes me think about retrying and especially what you're saying if things are happening in the background. Maybe there is an ephemeral error where the network timed out or something. But if it is given another shot, it might succeed on the second go. And I think there's a whole process of thinking about what happens when a process has to be retried and if there were any side effects that you didn't want to have committed the first time around, you know, but then something else that was supposed to happen and when the process happens again, things are very broken. So making sure that you are keeping things idempotent so that by undoing it again, there are not any unforeseen issues. JOËL: I heard you say that word commit here, and that's kind of a keyword to my mind. I immediately think database transactions. Is that the sense that you're thinking about this term here? Or does it have another meaning for you in this context? STEPHANIE: Yeah. I do think I used that word specifically because when I've run into this in the past, it has been around making database changes. I'm trying to think if there is another way that this might show up. I think even in something like sending an email, too, though it is a bit lower stakes. I've certainly, as a user, experienced when that goes wrong and just been [laughs] flooded with emails and being like, wow, this is annoying. And that's, I think, something valid to consider as well. JOËL: Yeah. You don't want that email job to be a thing that gets retried and just keeps failing because there's a nil error after the email gets sent. And so we just re-enqueue it, re-enqueue it, re-enqueue it, and the person ends up receiving 500 emails. STEPHANIE: What about you? Any thoughts about recoverable errors? JOËL: Yeah. I think really common for me is thinking about that in the context of a background job because those are things that I think are specifically designed to be retried if they fail; at least, a lot of job enqueuing systems assume that. When we write them, we don't always take that into account, but that's the system that we're working in. So that can be something as simple as marking somewhere that you have sent that email so that you don't resend it if that job ever re-executes. I think that goes to your point about idempotency earlier that you often want to write code that can get executed multiple times but doesn't necessarily do the action multiple times. It will do it at most once. And that's probably an interesting distinction to have is knowing what elements of your code need to execute at most once, versus as many times as the code is called, versus things that might get tried and then rolled back like a database transaction. And so then that will...I guess you could say it's at most once because you're writing it but unwriting it. But that plays out a little bit differently than something like an email where you can't undo sending an email outside of Gmail. STEPHANIE: Yeah, I love that undo button. [laughs] JOËL: You need some other mechanisms for that. STEPHANIE: Yeah. As you were talking about that, I was also thinking about the idea of failing gracefully, which I think also ties into the idea of recoverable. So this is not a development-specific example. But the idea of an escalator no longer working well; at least you can use it as stairs. So that doesn't mean that everything is totally broken and people are unable to get from one floor to another. So maybe if there is a network request that's touching data and that fails, you can at least fall back on something that's cached. That mindset, I think, really is important to think about at all the different levels we are talking about. JOËL: Yeah, or hopefully, even maybe some amount of graceful degradation. On a front-end app, you might not want to just crash the whole thing if one background request failed. So you can try again. You can be told, okay, try again in so much time. Maybe we automatically retry to make that same request with some sort of exponential backoff strategy. Or maybe we say, "Look, search is down for now. Here's a link if you want to go check a status page. Until then, other parts of the site are still working." I feel like we're getting back into what makes great product design and how great product designers have to make failure conditions. It has to be at the forefront of the thinking that comes to designing that product. STEPHANIE: Yeah, that's a good point. I think my initial feelings of being overwhelmed and stressed about dealing with errors may be because a lot of it falls on the developer if those things aren't accounted for. And we spoke a little bit earlier about, okay, what is within our realm or domain of actually being responsible for, and what can we loop in others for help with? JOËL: So we've been talking a lot about different ways of preventing errors, different ways of recovering, generally trying to make the whole experience really smooth. A slightly different philosophy around errors is rather than preventing them early is to fail early, like, fail early and loudly. And maybe you recover, maybe you don't. That depends on the context. But instead of putting so much effort into preventing errors upfront, it's better to just crash a lot or to fail loudly and deal with the consequences, or have a strategy for dealing with failure because failure is inevitable. How do you feel about that philosophy? STEPHANIE: Oh, I think it has a time and a place. One example I'm thinking of is if you don't want your application to be deployed if some configuration is not exactly how it needs to be for the app to run effectively. And so there is a matter of, like, okay, I really want to make sure that the DevOps team or the development team knows that something is very wrong because if this were to be deployed, the app would be unusable. And so that's an example to me of failing loudly but, ideally, not letting it affect end users because they're still using [laughs] the site on a different version. [laughs] JOËL: Right. I guess the classic example of that is for a Rails app, doing a Hash#fetch() on the environment to load up your environment variables instead of using the square bracket syntax so that as the app is booting and executing those initializers, it will crash if it encounters one of those and then fail to deploy if you're doing a deploy via something like Heroku. I've even sometimes when I'm adding environment variables, purposefully had them loaded in an initializer rather than maybe like in a class later on, specifically so that it would crash the app and prevent deployment if that environment variable was not set. STEPHANIE: Yeah, that's what I was thinking too, environment variables. Though I think even with that kind of mindset, you're either just delegating that responsibility to someone else down the line to either figure out how to accommodate or account for in a graceful manner. Or you are creating an environment where everyone is very stressed out [laughs] and having to fight fires. So I think it also requires a little bit of thought and isn't necessarily a strategy to just completely embody. [laughs] JOËL: I've noticed that bugs and errors often accumulate at the boundaries of systems or even subsystems or modules within a program. Maybe the place to apply the strategy of failing early and loudly is particularly valuable at those boundaries. But internally, within a subsystem or a module, maybe it's nicer to use other strategies for error handling. Does that sound like maybe a useful distinction to you? STEPHANIE: Yeah, I think subsystems was the keyword to me there because you don't want it to be such a catastrophe that it affects the usability of the app entirely. But that does still require some systems in place, I think, to respond to when that thing is failing loudly. JOËL: I think an example that came to mind for me is like you were mentioning earlier, a full-stack application. And if you've got the back end that's providing an API and something is wrong, I don't want that API to give me back garbage data and try to pretend that everything's okay. Let that API give me back some kind of error code. And I in the front end, I already know that the network is inherently unreliable. I'm planning to handle errors at that point. So it's fine for the API back end to fail loudly in this case. In fact, I think that's the optimal solution. STEPHANIE: Yeah, I think that's true because ideally, that error clues you into what kind of thing failed, and then maybe you can use that information more meaningfully than trying to guess at what happened with this bad data and then having to define some kind of error message in your app when ideally someone else who had more knowledge about it could have told you what went wrong. JOËL: And I guess the problem with not failing loudly or with an explicit failure is that if you try to just pass on some sort of value that will pretend to be like what you initially asked for, whoever's consuming that doesn't know that something went wrong. So then you use this garbage data, and you do some things and pass it along to the next person. And eventually, it may cause a failure three or four steps down the line. And now, trying to trace that, like, why did this fail? And it's not because something was wrong in Module D, or C, or B. It all comes back to oh, A had a problem but didn't crash or give us an error. It tried to pass its sort of best guess, like, this is probably okay. And then it just kind of moved all the way down the line. STEPHANIE: I'm imagining external API developers everywhere just nodding their heads in agreement. [laughs] JOËL: I've fought this on a local level as well. I was working on some kind of code for a JavaScript date picker plugin, and this was back in the jQuery days. It was some kind of...it was not a date picker. I think it was a typeahead drop-down thing. In some situations, I forget exactly how it would happen, but the input from there might be empty, but then that would get converted into an undefined value, which then JavaScript would convert to the string undefined, which would then get passed to something else that if it saw a string, it thought that was the thing that the user typed, and they would pass it through. And I think maybe in the end, I was looking at a crash ten functions away in the front-end code that had to deal with the input from this typeahead and being like, why am I getting these undefined? Or maybe it was a string NaN or something like that. Like, why am I dealing with these weird strings that should never have come out of this? And it turned out it was just kind of an edge case. It wasn't addressed in this component further on, and then it was kind of leaking strings that everybody else thought was sensible up until three or four jumps further down the stack. STEPHANIE: Yeah, that's a great point. I think it does go back to the idea of there being preventable errors. And then there are things that are truly not preventable because we live in a physical world [laughs] where computers talk to each other over the wire. And that distinction is, you know, perhaps the first being avoidable errors by writing resilient code. And the second being like, okay, in reality, there will be things that go wrong, and this is what we really have to watch out for. On that note, shall we wrap up? JOËL: Let's wrap up. [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: 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 and Joël attended RubyConf Mini, and both spoke there. They discuss takeaways and highlights from the conference. The core idea for this episode is explained in this article: Constructive vs. Predicative Data (https://www.hillelwayne.com/post/constructive/). This came up recently in a conversation at thoughtbot about designing a database schema and what constraints could be encoded in the schema directly versus needing some kind of trigger or Rails validation to cover it. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. RubyConf Mini (https://www.rubyconfmini.com/) Episode on CFP - The Bike Shed 352: Case Expressions (https://www.bikeshed.fm/352) Podcast panel: The Ruby on Rails Podcast Episode 446: I'm Giving A Talk on Thursday (https://www.therubyonrailspodcast.com/446) Slides for FP talk: Functional Programming for Fun and Profit!! (https://speakerdeck.com/jennyshih/functional-programming-for-fun-and-profit?slide=107) Episode on language: The Bike Shed - 356: The Value of Specialized Vocabulary (https://www.bikeshed.fm/356) Constructive vs. Predicative data (https://www.hillelwayne.com/post/constructive/) Avoid the Three-state Boolean Problem (https://thoughtbot.com/blog/avoid-the-threestate-boolean-problem) 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 something that's very recent in both of our worlds has been that both you and I, Stephanie, attended RubyConf Mini, and we both spoke there. What are some of your takeaways or highlights from the conference? STEPHANIE: Seeing you in person was definitely a highlight. I really enjoyed that. Because we're working remotely, I don't, you know, get to be in an office with you day to day. And it was really awesome to hang out with you, I think, for the first time as co-hosts of the podcast. And we both, I think, met some people at the conference too that were listeners. And it was really awesome to share that experience with you. JOËL: I had the interesting experience of several people who told me they recognized me by my voice, which I think is a common thing for podcasters, but as a new host, I was surprised by that. STEPHANIE: Yeah, that's weird. As a podcast listener, too, I definitely know exactly what you're talking about where it's like, oh yeah, I can identify someone by their voice. But to then be that person that people can recognize is pretty weird. I also really enjoyed being an audience member of the podcast panel that you are on at the conference with other podcast folks. It was moderated by Brittany Martin. And yeah, I just thought you represented The Bike Shed really well and spoke for both of us about podcasting in a way that I really appreciated. JOËL: And for any of our listeners who were not able to be there in person, Brittany has published that episode as a podcast, and we will link to it in the show notes. STEPHANIE: Another thing I really liked about RubyConf Mini was the smaller scale. I think it was about 150 or so attendees, which felt very different from traditional Ruby Central conferences with several hundreds of people. I heard a lot from other folks there that they really liked the regional aspect of it, the intimacy of the smaller conference. I think I got more of an opportunity to run into people that I'd met at the conference over the next few days. And there was, yeah, definitely a sense of tighter knit community there, you know, when you meet someone, and then you bump into them on the way into a talk, and then you can ask how their day was going and any highlights that they had. And yeah, I guess I haven't really attended a conference that size before, and so that felt like a very special experience for me. JOËL: I 100% agree. I think the smaller format definitely makes it a little bit more intimate, makes it much easier, I think, to build some of those social connections, to meet with people, and to have some good conversations. I think the format of the conference as well favored that. There were, I think, larger breaks between talks that encouraged people to hang out and talk. And, as you said, because it's smaller, you also get to see the same people over the course of a few different breaks instead of being like, oh, I met a stranger on the morning of day one, and then in the afternoon, I met another stranger. And it's just constantly introducing yourself. One thing that was really interesting to me is the experience of being a speaker is very different than just attending. As a speaker, you get to go to the speaker dinner and connect with a lot of the other speakers there. Some of them might be quote, unquote "famous people" that you're not quite comfortable just walking up to and introducing yourself. But in the smaller dinner, you just find yourself sitting next to them and enjoying some food or a drink and getting conversations. It's also much easier to have people come up to you during the conference. Because you're a speaker, people will come and talk to you. So if you tend to be a little bit more introverted, as long as you can get over your fear of being on stage and public speaking, it actually makes social connection interaction much easier to be a speaker. I would recommend to any of our listeners who were wondering how can I get more out of a conference? How can I get better connections, better conversations? Consider being a speaker. STEPHANIE: Yeah, absolutely. We've talked about this before; I think when we chatted about writing our CFPs for this conference that speaking doesn't have to be a really big, scary thing, but everyone has something to say. I think we had mentioned in previous episodes that your talk topic came out of just a discussion that you had internally, and you were like, wow, enumerables are so cool, like, let me dig deeper into them and just share what I learned. So I totally recommend it. And this conference was my first in real-life speaking opportunity as well, and that felt super different from my experience last time doing it virtually, you know, talking about how much I love that sense of community all the time. But it really felt true for me this time around, where I could see the audience react to the things I was saying, like, maybe go off the cuff a little bit. And then yeah, at the end, having people come up to me was really awesome to just talk about pairing, which is what I spoke about, and just share our experiences. And they asked what I thought about some things, and it was really cool to just be able to spread that knowledge around. And one thing I noticed you did a lot was come up to speakers after they wrapped up their talks. You were almost always the first person to get up and congratulate them and just get the ball rolling on following up on the things they talked about. Is that something that you really enjoy doing or find particularly valuable as an audience member or speaker? JOËL: Yes, both. I think, as a speaker, it's really validating to have people come up to you after the talk and either just tell you they liked the talk or ask a question. I generally don't like to do just open questions after a talk from the audience because then you get the classic; this is more of a comment than a question or people who will tell you that you had a typo on one of your code slides. Like, none of that is useful to anyone. So, if you're really interested, come talk to me afterwards. And then that actually makes me feel like my talk connected with people, and people were paying attention, people enjoyed it, people were learning. So I try to pay that forward as well for talks that I listened to, go up to the speaker, and tell them one thing that I appreciated about the talk or a thing that I learned, or something that got me excited in their content. STEPHANIE: Yeah, I'm sure that it's very appreciated. And it also breaks the awkward silence at the end when the speaker finishes and people aren't sure if it's okay for them to get up and start moving around. Yeah, I thought that was a really good way to kind of just encourage people to start chatting with each other and moving into those break times that we mentioned earlier, those opportunities to socialize. JOËL: Another thing that I think is really fun that you can do at in-person conferences, and I know you were doing it a lot, is going to see the talks of friends and colleagues and sitting in the front row and just being there to cheer them on and encourage them. Again, I think that makes a big difference when you are on stage, and you see these people who are your friends and colleagues there to support you. It gives you that boost of confidence. And when you're there in the audience, it's fun to cheer on somebody else. STEPHANIE: Oh yeah. You gave me a lot of thumbs-ups during my talk, and I really appreciated that. [laughs] So I'm curious if there were any talks that stood out to you that you got to see. JOËL: And I was really inspired by your talk, pair programming. I think there are a lot of things that I can take from that to improve the way I pair. I was also inspired by Aji's talk, Aji Slater, on automating manual tasks that you have to do in an iterative way. That one really hit home because, on my current project, I have been doing a lot of manual things. And I just have random snippets of code, like, some shell script lines or Ruby console lines, that I copy-paste out of Slack conversations because I've shared them with other people who are doing similar work. And I realized that a lot of his advice would apply to the work that I'm doing and how that could really make things better. So that was one of those talks I was listening to, and I was like, oh, you know what? Monday morning, when I go back to my project, this is something that I'm going to start doing. This is something I'm going to change in the way I do my day-to-day work. STEPHANIE: Yeah, absolutely. I have so many tasks that I would like to get automated, and think that one day I will magically have more time in my schedule to get to it. But I liked that his talk gave pretty concrete strategies for baking it into your regular, like you said, day-to-day workflow, and that lowers the activation energy to getting them done. And then those things can be iterated on and could eventually become, in an ideal world, a fully-fledged feature that you put together from doing those repetitive tasks. And yeah, they provide a lot of value not just to you but can eventually provide value to your co-workers and then even your users in the future. JOËL: Were there any talks that stood out for you? STEPHANIE: One talk that I really enjoyed was Jenny Shih's about Functional Programming for Fun and Profit. I have attended a lot of functional programming talks within the Ruby realm, at least to try to get a better sense of how it can apply to my work and the languages and paradigms that I use. And honestly, what I liked about it was that it didn't get too in the weeds about functional programming. What she did was provide mental models for understanding the paradigm that I think was a good vehicle for understanding things very generally. And, for me, like,¬¬ a talk, it's really hard to pay attention to lines of code and to read code on the fly while people are presenting. For me, that is just not how I like to consume that information. And so she provided themes and, like I said, those mental models, which I know you really like to use a lot too in teaching people new concepts. For me, I didn't fully learn what a monad was, once again, but at least having that repeated exposure to those foundational aspects, I think, will eventually lead me to be able to grok those things a little more comprehensively the next time I see it or whenever I decide to dig deeper. JOËL: What was a mental model that was shared that connected with you particularly? STEPHANIE: So one of the main mental models that she shared was thinking about a program in terms of these three dimensions: value, behavior, and time. She had a nice slide that showed the difference between the object-oriented paradigm, where value and behavior are contained by objects, where time is kind of inherently wrapped up in those objects that hold information about the state through values and behavior. Whereas in her functional programming example, those three dimensions were a bit separate. And I found that distinction to be really helpful in separating things that felt very implicit before, but it was nice to see them broken out into very clear concepts in terms of building blocks of a program. JOËL: So it's helpful then when thinking...when you look at code, if you can think about it in those three different dimensions to help think about, am I taking a functional or other approach in this particular dimension when working with this code? STEPHANIE: Yeah, exactly. I think it also gave me more of a vocabulary to describe the pros and cons of each and a lens of thinking about which I might want to choose for the particular problem at hand. JOËL: So you mentioned there's a visual for these three dimensions from the slides. Are those slides publicly available? STEPHANIE: They are. I will link to them in the show notes. JOËL: So all of these talks were recorded. They're not yet available to the public, but I think the plan is to publish them on YouTube sometime in the new year, so that means probably January 2023. And a big shout out to the AV team and everyone who is involved in recording these. STEPHANIE: Yeah, I am definitely looking out for a link to my talk so I can send it to my mom. I also wanted to give a little shout-out to the organizers of RubyConf Mini: Jemma Issroff, Emily Samp, and Andy Croll. JOËL: Woo! STEPHANIE: They put on just a really awesome conference, and I feel very grateful that I got a chance to attend with you, Joël. JOËL: It was definitely a delightful experience. STEPHANIE: Delightful. That's a reference to Joël's talk for those of you who are listening. 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: Coming back from the conference, I recently had a really interesting conversation with some other colleagues at thoughtbot. We were looking at a database schema for a new application and talking about some of the trade-offs involved in how that schema is structured, so what tables we want to have. Do we want to have indexes? Things like that. And particularly around some of the assumptions are business rules that would come into play. So we're looking at...we'd drawn out this Entity Relationship Diagram (ERD). In it, we're looking at all the tables, and something that comes up immediately is like, oh, it's possible to have some bad data that could show up in these columns. Or it's possible that this relationship could exist where this table has a foreign key on this table, but really, that should never happen in this particular way of working. And so then the question became, how do we try to prevent these things that currently the schema allows but that are not valid in this particular business domain? Do we want to change the schema somehow and make that stricter or find some way to prevent it? Do we want to add some kind of validation that will check some business rules first before inserting or updating a record? I'm curious, have you ever been in a situation like that where you had to balance those two approaches to enforcing business rules on your database? A classic small example of this is a situation where let's say, you have a users' table and you have a name column on there. And you want to ensure that that name must always be present; all users must have names. Do you try to enforce that via the schema with a NOT NULL constraint? Or maybe you try to enforce that with a validation, maybe a presence validation at the Rails level. Or if you're really into SQL, maybe some fancy trigger, but do it in a validation style rather than trying to force this using the schema. And our particular scenario was a little bit more complex than just one column; it was more to do with associations. But I think this sort of problem shows up even in constraints as small as a required field. STEPHANIE: That's really interesting. I think that, in my experience, when we are spinning up new tables, at that point, we do try to put some intentional thought into what the schema should look like and what requirements we might need to encode at the database level. But things that are more complex might need a little more code, like Ruby code. I have then pushed to an ActiveRecord validation. One thing that I think is important to know is that when you do set those things on the schema, it's harder to change. And so you usually have to feel pretty confident that that's what you want. Otherwise, you'll run into issues later if that does have to change and making changes to whatever existing data you might have. But it's also pretty common to just do your best when you are deciding on a database schema and then having to make adjustments down the line as you know more about your domain. JOËL: This conversation reminds me a little bit of the idea of database normalization. I think that might almost fit as a subset of general tactics of using the schema to ensure your data is more correct. When you are generating new tables, let's say you're creating a greenfield app and you need to create four or five tables; how much emphasis do you put on database normalization when you're initially designing those? STEPHANIE: I think for a greenfield project when you are setting everything up and creating tables for your main domain models, there is an aspect of it that should be considered because you're in this unique position where nothing really is in existence yet. And you do want to try to set yourself up to be successful and hopefully have information about your main use case for this app and can kind of make decisions about the schema then. At least in my experience, that has been part of the conversation, though, to be fair, because it's so early, you do have the opportunity to change things without as much effort or pain. But I think it's worth considering when you're just sitting down and working through what those models are going to look like. JOËL: And for our listeners who may not have heard the term normalization before, it's a series of...you can think of them as rules that you apply to your database design to try to avoid data redundancies in your tables. There are different levels of this; they're typically referred to as normal forms. So you'll see things like first normal form, second normal form, third normal form; those are kind of the fancy terms for them. But they generally involve breaking out other tables so that you don't have data redundancies. And in many ways, this is similar to principles such as the single-responsibility principle that we apply to objects when we're designing our objects in an OO system. But this is more at the table level for databases. STEPHANIE: I do think that it is so hard, maybe even impossible, to plan something out, to not have any of those redundancies, to begin with. And I do think sometimes they are a bit inevitable. But I also have had the experience of having to figure out what the heck I'm looking at when I am querying data and see all these things that are duplicated or maybe slightly different. And yeah, I think when you are in that position of starting a greenfield application, it is really interesting to see how you make those decisions about what needs to be enforced and where. Where did you end up landing, or what did you discuss in this conversation with the co-worker? JOËL: I think we went with a bit of a hybrid approach. Some things, we can use the schema to prevent bad data, and then some things either cannot be represented with a schema, or it's possible, but it's really cumbersome and painful. And so, we chose to try to enforce it with a validation. To me, this feels very similar to a problem in typed languages. So some communities that use a lot of types try to use those types to only allow data to come through that's in a valid shape. And so you'll hear things like make impossible states impossible or make illegal states unrepresentable. And that works for many things, but it's not always possible to enforce all of your business constraints through a schema. Or sometimes it's possible but just not practical. And so, I think there is a balance of finding when you can use the schema or when it's better to use the validation.¬ STEPHANIE: Yeah, I think my general rule of thumb is, like I mentioned earlier, things I feel really confident about that we want to make sure that we have in our database or in our data for sure. I do lean towards requiring those in a schema, and it also communicates that confidence or communicates that intent that it's something that at one point was decided is important. And so, if a future developer comes in, it would take a lot of work for them to write a migration, to remove some database constraint. Whereas I think sometimes validations at the Rails level are potentially a little more open to change and then even more so if you get to validating on the client side. JOËL: That can get to be a really, like, it's a useful tool, but one that you can really hurt yourself with. If you modify your validations at the Rails level or at the front-end level, but then you don't backfill those changes on your data in the database, then you might have records in your database that if you were to load them into memory and hit save on them again, would refuse to save because they no longer match the validations. And on longer-lived applications, I've seen that happen sometimes where not all rows in the database pass the Rails validations. STEPHANIE: Yeah, I think I've seen that be a problem either for developers who then have to backfill that data or write some migration to change some of the data to meet the new requirements, or just unexpected bugs on the users who discover something new but like you said, have been there long enough before those things were implemented. JOËL: The more I think of this, I think maybe constraints that are enforced at a validation level might still require changing the data in your database. So if you had a constraint enforced via a schema, you don't have a choice. You have to write some way to migrate that data so that it fits the new schema. You can kind of lie to yourself with validation and not change the historic data, and sometimes that is the case; you want to keep the old data and only prevent new data from being written in the old format. But if you need consistency, then you probably need a data migration regardless of which approach you take. STEPHANIE: Yeah, that definitely sounds like the more robust way to go about it for sure. JOËL: I have an article that I like to reference a lot by Hillel Wayne on Constructive Versus Predicative Data, which is basically looking at these two general approaches to enforcing data correctness and formalizing them a little bit. So do you try to enforce them based on the construction or the shape of the entity that you're creating, be that a database table, an object, a type, something like that? Or do you enforce it via some kind of predicate? So that could be a validation or other similar logic that runs kind of at runtime to enforce your constraints. STEPHANIE: That's interesting. I hadn't heard of those terms before, but I think they provide a lens through which you can look at the problem. Did the article end up suggesting different strategies for solving that problem, or was it more theoretical in different ways to look at it? JOËL: I think the article does two things. First, like you said, it gives us the words to talk about those approaches. And having those labels now, I start seeing them everywhere. I see them in databases, I see them in objects, I see them when doing types across a variety of languages. So that's already a huge win for me. I think you and I had done an episode a couple of months back where we talked about the value of having labels to put to ideas. And I think for me reading that article gave me those two labels. And all of a sudden, it really helped to make connections that I wasn't seeing before. The second thing that the article does is, I think, explore some of the limitations that each approach has and when you might want to use one versus another. The constructive approach, so using a schema, is more consistent because you know it is impossible for the program to create data that's in the wrong shape. That being said, not all constraints can be represented in a constructive manner, or it might be possible but really cumbersome. Also, sometimes it's not really invalid data; it's just sort of undesirable data. So you might want a looser schema. And let's say that you're storing some kind of intermediate state or some kind of raw input from another system that you might want to layer validations on top of, but you don't want to reject that data out of your database. You want that sort of incomplete or imperfect data in your system. Something that I find myself doing more and more these days when I create new tables is to really lock down the schema as much as possible. I think that might be contrary to maybe the way a lot of people in the community like to work. Some people might prefer to start with a very loose schema with no constraints and then work towards making things stricter as they explore the domain, and that's kind of the default that Rails has. If you're creating a new table, all columns, for example, are nullable by default. Personally, I will put a null false on every column and every migration that I make unless somebody can make a convincing case otherwise, and even then, I might try to think of is there any possible way that we could avoid that scenario and put that null false. Part of the reason for that is that it is much easier to loosen constraints on existing data than to tighten them afterwards. So if I have a column where no value is allowed to be null, and then later on we decide, you know what? It is okay for some of them to be null, I can change the requirement on that column, and I don't need to make any changes to the existing data. It just works. If the reverse happens, if I have a column that allows a bunch of nulls and then I want to make that column required, now I have to go and find a way to backfill all the empty spots in that column. And that could be a very challenging process. It might even be impossible. There might be some values there that it's just like, the user did not supply them at the time because we didn't ask for them. And now there's nothing we can put in there. So do you put in, like, unknown or not available? Then you have to ask yourself some really difficult questions about your data. STEPHANIE: Yeah, absolutely. I think I agree with you there. Another thing I like to do is provide default values for columns, especially ones where they can't be null, because, like you were saying, that helps me have a better understanding of just what is going on in the database. An issue I have seen come up involves a Boolean column where if a default value of false, for example, if that's what we're going with, is not encoded in the schema, you end up with potentially three values for a Boolean, which would be true, false, and null, and that I think has been -- JOËL: The infamous three-state Boolean. STEPHANIE: Yeah, exactly, the three-state problem, which is just inherently contradictory to what a Boolean is, to begin with. And I've definitely run into issues with that where you have to decide, or figure out, or write code to determine is null false? Is that what we mean here? It's not clear. But if you, like you said, locked it down at the beginning, provided those default values, that puts in those guardrails to prevent things from getting out of hand. JOËL: It also makes it easier for users of your database, application, whatever to interact with your code. I've run into this a lot when working with GraphQL APIs. And the default in many GraphQL server implementations is to make all fields nullable by default. When you build your schema, you have to add some extra things there to say, "This field is non-nullable," which means that a client that's now consuming it, anytime they deal with the data they need to check, is it present or not? You can't have the confidence that that data is there. And so it can force a lot of extra checks on the client. Or I guess you could just take it on faith and hope nothing breaks. STEPHANIE: Yeah, it's funny you mention that because I definitely think there's like spheres of impact. So as a developer, you maybe start having to write code that checks those kinds of things, like if it's null or not in your code. Then that can even extend to, like you said, your users or consumers of the API, who then have to contend with data that they have no control over. And I've been there too, and that can be frustrating as well. JOËL: We've talked a lot about data correctness and different ways to achieve it, different strategies. Why is this something that we care so much about? STEPHANIE: I think data correctness is really important from a developer experience perspective. And it's way easier to fix a bug in your code than it is to wrangle a lot of accumulated bad data. JOËL: Yeah, sometimes bad data is not fixable at all, and those are situations where you have a really bad day as a developer. STEPHANIE: Agreed. JOËL: Well, 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 was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

In this tour-de-force, Mike Dalessio – Engineering Director at Shopify – and Evan Phoenix – self-described “long-time Rubyist” – join us for a practical discussion of all things Ruby! Ruby is a beautiful language, and we're really excited to cover the history and present of this language with two experts. 00:01:03 Introductions00:01:49 Mike's Ruby journey00:12:28 Evan's own Ruby experience00:18:20 The pickaxe book00:20:34 Weird programming interests00:25:11 MINASWAN00:30:33 Language conferences00:36:38 Wrong answers on StackOverflow00:41:53 RubyCentral00:44:50 In-depth examination of Ruby00:47:57 How Shopify sticks to vanilla Rails00:50:28 A tale of two developers00:59:59 Bringing Ruby up to Python's level01:04:48 Shopify's largest app monolith01:11:12 Tuning the knobs01:18:01 How not to learn the hard way01:18:57 Opportunities at Shopify01:29:14 Working with the RubyShield program01:32:07 Rails for API servers01:33:21 Mike and Evan's advice for listeners01:36:00 FarewellsResources mentioned in this episode:Links: RubyCentral: Website: https://rubycentral.org/ RubyShield: https://rubycentral.org/ruby-shield Twitter: https://twitter.com/rubycentralorg Shopify: Website: https://www.shopify.com/ Careers: https://www.shopify.com/careers Dev Degree Program: https://devdegree.ca/pages/program HashiCorp Website: https://www.hashicorp.com/ Careers: https://www.hashicorp.com/jobs Mike Dalessio: Website: http://mike.daless.io/ Twitter: https://twitter.com/flavorjones Evan Phoenix: Website: https://github.com/evanphx Twitter: https://twitter.com/evanphx RubyConf 2022 (Nov. 29 – Dec. 1, 2022):Website: https://rubyconf.org/ Other Episodes:Episode 47: RubyShow Link: https://www.programmingthrowdown.com/2015/10/episode-47-ruby.html  References:“The Pickaxe Book” aka Programming Ruby: The Pragmatic Programmer's Guide 2nd Edition:Amazon: https://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055  If you've enjoyed this episode, you can listen to more on Programming Throwdown's website: https://www.programmingthrowdown.com/ Reach out to us via email: programmingthrowdown@gmail.com You can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM  Join the discussion on our DiscordHelp support Programming Throwdown through our Patreon ★ Support this podcast on Patreon ★

Mina Slater is a developer on Mission Control, thoughtbot's DevOps and SRE team and serves as a Scholarship program organizer with Ruby Central. Mina details why it is humbling to embrace the cloud and what SRE means. She and Brittany then share their hot takes consulting versus working on a product team. Show Notes & Links: thoughtbot Mission Control (https://thoughtbot.com/mission-control) Site Reliability Engineering: Google (https://sre.google/) Mina Slater (@minar528) on Twitter (https://twitter.com/minar528) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. AppSignal (https://www.appsignal.com/rorpodcast) Monitor your apps from A to Z: error tracking, performance insights, server metrics, uptime pages, custom dashboards, and more. AppSignal works for all popular Ruby frameworks and automatically instruments and creates beautiful dashboards for Sidekiq, Active Job, and other integrations. As a listener of The Ruby on Rails Podcast, you get a 10% discount and a box of sweet treats. Start your 30-day free trial at https://www.appsignal.com/rorpodcast (https://www.appsignal.com/rorpodcast).

Emily is guesting as co-host this week with Jemma and Brittany! The trio celebrate Emily's new role at Shopify and discuss taking breaks between roles. Emily and Brittany just wrapped up reviewing CFPs for Railsconf so Jemma asks them about the patterns they observed. They wrap up by talking about their (not) green thumbs and home desk setups. Show Notes & Links: Sorbet · A static type checker for Ruby (https://sorbet.org/) Jemma's Tweet to Ruby Central (https://twitter.com/JemmaIssroff/status/1499096595282870273) Sponsored By: Honeybadger (https://www.honeybadger.io/) Honeybadger makes you a DevOps hero by combining error monitoring, uptime monitoring and check-in monitoring into a single, easy to use platform. Go to Honeybadger.io (https://www.honeybadger.io/) and discover how Starr, Josh, and Ben created a 100% bootstrapped monitoring solution. Scout APM (http://scoutapm.com/rubyonrails) Try their error monitoring and APM free for 14-days, no credit card needed! And as an added bonus for Ruby on Rails listeners: Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at http://scoutapm.com/rubyonrails (http://scoutapm.com/rubyonrails).

[00:00:52] The guys chat about being at RubyConf, how they recorded a live episode with six people, what they talked about, and something about a stellar ending.   [00:02:50] Andrew and Jason talk about what happened from the first day of RubyConf and from then on, between meeting up with people, eating with friends, doing a lot of walking, hugging, and talking with so many people. [00:06:39] Jason tells us more about Matz's talk on the Ruby 3 Nexus.[00:10:49] Jason explains another thing Matz talked about regarding how there will not be a lot of language features focused on right now, but more performance and tooling. [00:12:38] Chris tells us about the new screencast he just did on the new load_async in Rails 7 you should check out. [00:16:25] We hear some funny stories from Jason about how he saw Andrew “Hella triggered” two times this week.[00:17:53] The guys discuss the best thing about being at conferences especially since they haven't happened in two years due to COVID. [00:20:37] The conversation turns to impromptu get togethers at the conference and some stories from Jason, and Andrew announces they scheduled some upcoming guests for the podcast from this conference so stay tuned. [00:24:01] Jason acknowledges the recent passing of Mike Rogers and all he did for the Ruby community.  [00:25:51] New in the Ruby world, Ruby 3.1.0 the alpha came out and the changes with YJIT and how the app will be faster. [00:28:12] Find out what who was dressed in Adidas gear all week at the conference and two things that Jason doesn't like! ☺[00:29:47] Jason and Andrew tell us what their favorite part of the conference was.[00:35:20] Andrew gives a big thank you to Ruby Central for doing the conference, the Ruby community, and the organizers and sponsors. Also, Jason and Andrew tell us their favorite things they learned from some of the talks. Panelists:Jason CharnesChris OliverAndrew MasonSponsor:HoneybadgerLinks:Ruby Radar NewsletterRuby Radar TwitterRubyConf 2021Parallel ActiveRecord Queries with load_async in Rails 7-GoRails with Chris OliverRuby 3.1.0 Preview 1 Released-Ruby News

Vlado Cingel recounts his story where he needed common table expressions within SQL for a project he was working on and wrote a patch to AREL and ActiveRecord which he submitted to the Rails Core. Since it hasn't been accepted, he's supporting it as a gem. Vlado explains what Common Table Expressions (CTEs) are, how they work, and where they're used. Panel John EppersonLuke StuttersValentino Stoll Guest Vlado Cingel Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Links GitHub | vlado/activerecord-cteOrganising complex SQL queries in RailsGitHub: Vlado Cingel ( vlado ) Picks John- Digital Storm: Custom Gaming Computers & Gaming PCsLuke- Pitch PerfectValentino- Ruby TogetherValentino- Ruby CentralValentino- The Ruby VM a speedrun - Penelope PhippenVlado- The Wood Whisperer Guild - Online Woodworking SchoolVlado- Polished Ruby Programming Contact John: Rock Agile ConsultingGitHub: John Epperson ( kirillian )LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Vlado Cingel.

Vlado Cingel recounts his story where he needed common table expressions within SQL for a project he was working on and wrote a patch to AREL and ActiveRecord which he submitted to the Rails Core. Since it hasn't been accepted, he's supporting it as a gem. Vlado explains what Common Table Expressions (CTEs) are, how they work, and where they're used. Panel John EppersonLuke StuttersValentino Stoll Guest Vlado Cingel Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Links GitHub | vlado/activerecord-cteOrganising complex SQL queries in RailsGitHub: Vlado Cingel ( vlado ) Picks John- Digital Storm: Custom Gaming Computers & Gaming PCsLuke- Pitch PerfectValentino- Ruby TogetherValentino- Ruby CentralValentino- The Ruby VM a speedrun - Penelope PhippenVlado- The Wood Whisperer Guild - Online Woodworking SchoolVlado- Polished Ruby Programming Contact John: Rock Agile ConsultingGitHub: John Epperson ( kirillian )LinkedIn: John Epperson Contact Luke: GitHub: Luke Stutters ( lukestuts ) Contact Valentino: Doximity Technology BlogWork @ DoximityGitHub: Valentino Stoll ( codenamev )Twitter: V ( @thecodenamev ) Special Guest: Vlado Cingel.

In this episode, we talk about the explosive Facebook internal documents, a merger between Ruby Central and Ruby Together, and the short lived removal of .NET's Hot Reload feature, which had a lot of developers frustrated and confused by the decision. Then we speak with Brigit Murtaugh, Program Manager II at Microsoft, and João Moreno, Principal Software Engineer for VS Code about how they created a new lightweight version of VS Code that can run fully in the browser. Show Notes DevDiscuss (sponsor) CodeNewbie (sponsor) The Facebook Files: A Wall Street Journal investigation Facebook's Lost Generation Facebook Wrestles With the Features It Used to Define Social Networking Facebook Failed the People Who Tried to Improve It DeepMind's XLand, Android 12 Beta's Camera Switches, a Colorism Issue With Face Filters, and a Senior's Robot Companion Ruby Together and Ruby Central, Coming Together Update on .NET Hot Reload progress and Visual Studio 2022 Highlights Microsoft angers the .NET open source community with a controversial decision Is There an Echo Chamber? vscode.dev(!)

In this episode, we talk about Ruby and Rails with Richard Schneeman, principal engineer at Salesforce and Heroku Ruby language owner, and Penelope Phippen, staff software engineer at Stripe, and a director at Ruby Central. Show Notes DevNews (sponsor) CodeNewbie (sponsor) Scout APM (DevDiscuss) (sponsor) Cockroach Labs (DevDiscuss) (sponsor) Ruby Rails Rubyfmt RubyConf RailsConf DeadEnd Inside the all-hands meeting that led to a third of Basecamp Employees Quitting

We often vaunt the greatness of Open Source and skirt some of the lesser seen issues while focusing on the greatness of the communities we are a part of. What is it like for solo maintainers? Can we set our expectations on people writing code on nights and weekends, people who have other aspects to their lives? How do we keep vulnerable people in Open Source safe? Fortunately, our guest for this episode, Penelope Phippen, has navigated these waters. Penelope is the maintainer of a rubyfmt, rspec, and is involved in Rust, while also working as a full-time engineer and on the Board of Directors at Ruby Central. That said, there is so much more to Penelope than her job description. Like her Battlesnake Twitch stream. Give a listen to someone with experience in so many aspects of the Open Source world.

Marty Haught and Evan Phoenix, Directors of Ruby Central, guested on the show to explain Ruby Central's place in our community, how Railsconf 2021 came together and what we can expect from the upcoming Rubyconf 2021 as a dual virtual and in-person conference.

Marty Haught and Evan Phoenix, Directors of Ruby Central, guested on the show to explain Ruby Central's place in our community, how Railsconf 2021 came together and what we can expect from the upcoming Rubyconf 2021 as a dual virtual and in-person conference.

Marty Haught and Evan Phoenix, Directors of Ruby Central, guested on the show to explain Ruby Central's place in our community, how Railsconf 2021 came together and what we can expect from the upcoming Rubyconf 2021 as a dual virtual and in-person conference.

Marty Haught and Evan Phoenix, Directors of Ruby Central, guested on the show to explain Ruby Central's place in our community, how Railsconf 2021 came together and what we can expect from the upcoming Rubyconf 2021 as a dual virtual and in-person conference.

In this episode, we about federal and state antitrust lawsuits against Facebook, and a new DNS technique backed by Apple, Cloudflare, and Fastly called Oblivious DNS. Then we speak with Hector Monsegur, security researcher and former blackhat hacker, about a major hack against multiple government agencies. Then we chat with Penelope Phippen, tech lead at Stripe, and a Director at Ruby Central, about the release of Ruby 3.0. Show Notes DevDiscuss (sponsor) Triplebyte (sponsor) CodeNewbie (sponsor) Vonage (sponsor) Improving DNS Privacy with Oblivious DoH in 1.1.1.1 U.S. and States Say Facebook Illegally Crushed Competition U.S. Agencies Hacked in Foreign Cyber Espionage Campaign Linked to Russia Ruby 3.0.0 Preview 2 Released

As an industry, tech is not well equipped to accept when people change their names. This problem effects a range of people, including those who have a change of marital status. However, it can especially effect the security of those who are survivors of domestic violence, and those who are trans, who have to suffer through deadnaming by their tech accounts. This constant barrage of deadnaming can be very psychologically and emotionally harmful. DevDiscuss hosts Ben Halpern and Jess Lee speak with Penelope Phippen, director at Ruby Central, and author of the DEV post, "Changing your name is a hard unsolved problem in Computer Science," about this issue and what can be done to make it better. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Ruby RSpec Rails Ruby Central RubyConf RailsConf RuboCop Go Format Changing your name is a hard unsolved problem in Computer Science Falsehoods Programmers Believe About Names GitHub One Medical Whipping Girl: A Transsexual Woman on Sexism and the Scapegoating of Femininity GLAD SheCodes LivingSocial Rubyfmt

Penelope Phippen makes Rubyfmt, and was previously a lead maintainer of the RSpec testing framework. She’s been writing Ruby for just about a decade, and still remembers 1.8.6. She and Brittany discuss Rspec, Ruby Central and her thoughts on the Ruby community.

Penelope Phippen makes Rubyfmt, and was previously a lead maintainer of the RSpec testing framework. She’s been writing Ruby for just about a decade, and still remembers 1.8.6. She and Brittany discuss Rspec, Ruby Central and her thoughts on the Ruby community.

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

Parent Driven Development Episode 029: Organizing Conferences 00:57 Balancing Conferencing with Parenting Andy has organized RedDotRubyConf (https://www.reddotrubyconf.com/), still organizes Brighton Ruby (https://brightonruby.com/), and has spoken the past few years at RubyConf (https://rubyconf.org/). Andy also puts out an email newsletter, with one Ruby/Rails technique delivered with a ‘why?’ and a ‘how?’ every two weeks. It’s deliberately brief, focussed & opinionated, and called One Ruby Thing (https://onerubything.com/). Chris helps to co-organize Ruby For Good (https://rubyforgood.org/). Systems, systems, systems. Staying in the speaker hotel during crunch time. Getting paid helps. Having no co-organizers = no extra communication challenges. Relying on your partner. Staying local helps. Having a venue. 06:52 Conference Sizes: How Big is Big? Andy runs Brighton Ruby as a single track, one-day conference of 300-400. Ruby Central (http://rubycentral.org/) conferences by comparison are up to about 1,000 attendees and multi-track over 3-4 days. Ruby For Good is about 80 people, but has less of a conference feel because it's groups of people hacking on different projects over a few days. 09:46 Classifying These Gatherings as "Work-Adjacent Hobbies" Benefits the career. Meeting, networking, and making friends. Feel-good factor. Prioritization. Time frees up as kids have gotten older. 19:30 Family Involvement Kids on stage are cute. Teenagers can help volunteer! Osmosis of exposure. This is what mom/dad does! Showing that work does not necessarily equal drudgery. 22:30 Behind-The-Scenes Tradeoffs The best track at any conference is the speaker track. Coaching, mentoring, and cheering on first-time speakers. Repetition of putting on conferences over the years = it gets easier, more fun, and less stressful. Atomic Habits (https://www.amazon.com/gp/product/0735211299/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=therubyrep-20&creative=9325&linkCode=as2&creativeASIN=0735211299&linkId=a6154fb4886e2b76620e69e1d1f699a2) 28:21 Meal Kits and Meal Planning Conversation We all have tried them. We all have opinions. We are definitely open for sponsorship. Email us!

Have you ever found yourself working on a side project because you thought you had to and not because you wanted to? Our guest for this episode of CTO Studio has and he also found out why it’s okay not to finish that side project. Evan Phoenix is the lead engineer on the private Terraform enterprise  at Hashi Corp, and the Director of Ruby Central. He’s also been a CEO of a start up and regularly finds time to try out side gigs of his own. Today he tells us how he carves out the time for fun engineering projects and why sometimes it’s okay not to finish those side projects. You’ll hear from Evan on those topics and more on today’s CTO Studio. In this episode, you’ll hear: Is it okay to do something even if you think you are not the right person for the job? Why everything we do doesn't have to become a business. What is the "for market" challenge? Why does he prefer Go over Rust and C++? How to put the fun back in your side projects. And so much more!   We start off by talking about Evan's scariest childhood movie and how we met at a Ruby conference and became friends. Then we segue into talking about his current role at Hashi Corp: he is the lead engineer on the private Terraform enterprise. He came to that position via his previous start up, Vectra. Vectra eventually became a logging SaaS and Evan and his team worked to build it for 8 or 9 months before their financial runway was depleted. At that point, Evan had to figure out what to do next.  After struggling with the decision, Evan realized he didn't like being a CEO and so they decided to close Vectra. Along the way, he and his team had been talking to Hashi Corp about what they were doing. When Vectra closed Hashi Corp invited them to come over and work there. For Evan it was the best case scenario. He didn't like being a CEO, but he liked working on interesting problems and have some say in what he worked on. Hashi Corp is the perfect place that allows him to do both. I was curious when he first thought of being the founder of his own company, and why that interested him. Evan explains he wanted what he thinks every founder thinks they are getting when they start their own company: control to do whatever they want to do. They make all the decisions. If they don't want to do something then they don't do it, and vice versa. But the reality changes when the business involves more than just you or you and another person. If you take on investors you no longer have complete control. In Evan's case his family and friends invested in his business so not your typical investors, but he was still aware of risking other people's money. And that awareness changed and altered his own risk tolerance. So now he gets to enjoy his work at Hashi Corp and have fun projects on the side. He says he start a new project every couple of weeks and he does it for him. We go on to talk about engineering simply for the sake of enjoyment, before we discuss his time at Living Social and Splice. We also talk about how he manages his time as a family man with a wife and two daughters: when does he work on his personal projects? He tries to be kind to himself and he works on them when he has the time. In the past, he would've beaten himself up for not getting more done on something, but now he doesn't. Instead, he talks to his wife and tells her he wants to work on something. She tells him she wants to do her own thing and then they do their own thing in the evenings. On the weekends his daughters still have nap times so when they nap he works on his projects. But sometimes he uses those two hours to watch a TV show or do something - and he is now kind to himself about it and just does what he wants. If he wants to work on his project then he does; if he wants to watch Netflix then he does. We then talk about what he is seeing at Ruby conferences for 2018 and 2019. He says at every conference they ask the audience to show their hands if this is their first time in attendance, and typically about half of the crowd raise their hands. So every year about half of the people are going to their first Ruby or Rails conference. And there's a core group that goes to all the conferences and has since the beginning. They make up about 20% of the attendees. Their Ruby conference is around 800 people and the Rails conference is about 1200. They have found about 30% of people return after their first time attending one of the conferences. Since he's been doing these two conferences for so long, does he continue because these are his people? Yes, it's really about community far more than the actual technical stuff now. He cut all of his professional chops in the Ruby community so he has tons of friends from there. He goes to the conferences to see them and hang out with them. He knows this is true for other people, so it's important that the conferences he puts on create an environment that welcomes people and keeps them connected to their friends in the community. As a conference organizer, it's important to remember that every session doesn't have to be something you've never done before. They try to ensure their space is conducive to hanging out. And there are at least a few sessions he would be interested in because he understands he represents a weird slice of the Ruby and Rails community having been to so many conferences. Evan knows if he is interested in a topic then those talks should appeal to at least some of the people in attendance, too. We wander back to talking about Hashi Corp and finish our chat with Evan telling us what Terraform is, when to explore using Terraform and where infrastructure as a service is going in the future. Listen in for those conversation topics and more on this edition of CTO Studio!

On December 28th, the CFP opened for Railsconf 2019. This year’s conference will be from April 30 to May 2 in Minneapolis, Minnesota. Marty Haught, one of the Directors of Ruby Central, came on to answer your burning Railsconf questions.

On December 28th, the CFP opened for Railsconf 2019. This year’s conference will be from April 30 to May 2 in Minneapolis, Minnesota. Marty Haught, one of the Directors of Ruby Central, came on to answer your burning Railsconf questions.

The Ruby Central Opportunity Scholarship/Guide Program (https://rubyconf.org/scholarships) 02:13 – Superpowers: Flying, Changing Diapers, and Empathy! 03:21 – Scholars’ Favorite Parts of the Conference 06:58 – Conferencing as an Introvert: Having Conference Buddies! 08:06 – Meeting New People 10:15 – Challenges of Conferencing 11:55 – Navigating Conference Parties and the General Hubbub 17:35 – Overcoming Pressure 21:09 – Lightning Talks 26:31 – Live Mob Programming Event 30:07 – Advice For Future Scholars 34:50 – Coming to Tech From Different Backgrounds and All Walks of Life This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode). To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guests: Christine Seeman, Jennifer Tran, and Jeremy Schuurmans.

Parent Driven Development Episode 014: Conferencing After Babies 00:16 Welcome, Tess (https://twitter.com/GriffinTess) and Sean Griffin (https://twitter.com/sgrif)! Tess is a Site Engineer at GitHub (https://github.com). Sean is a developer at Shopify (https://www.shopify.com/), renowned Rails committer, the creator of the Diesel Framework (http://diesel.rs/), host of The Yak Shave (http://yakshave.fm/) podcast, and a former host of The Bike Shed (http://bikeshed.fm/) podcast. 02:14 Deciding on Conference to Go To and Speak At Conferences who offer on-site childcare are very attractive. Shoutout to Ruby Central (http://rubycentral.org/) conferences and Rust Belt Rust (https://www.rust-belt-rust.com/)! 09:56 Evening Childcare Going through conference organizer recommendations is preferencial because they spend a lot of time scouting the cities, however, services like UrbanSitter (https://www.urbansitter.com/) and Care.com (https://www.care.com/) are options in a pinch. Conferences that offer child/kid-friendly after-hours activities are also great for parents. It seems like more conferences like that are popping up and opting for less bar atomosphere gatherings.

Chad Fowler is an author, developer, speaker, and investor. He's been a CTO, he founded Ruby Central, the non-profit behind RubyConf and RailsConf, and is a recognizable tech figure, particularly in the Ruby community. But before he knew what code was, he was a professional musician. He shares how he switched careers without a computer science degree and how he's ended up with such an incredible tech career. He also shares how he's managed his bipolar disorder over the years, and how mental health has affected him and his career. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Ruby Central RailsConf Ruby Gems Wunderlist Delphi Perl Novell Directory Services (NDS) Smalltalk Matz Rails Recipes (book) Dave Thomas (CodeNewbie Podcast interview) Programming Ruby (book) "How to become accomplished" (video) What is Linux? Codeland Conf Codeland 2019

20 Years of Web Development with Avdi Grimm and Sarah Mei TableXI is offering training for developers and product teams! For more info, visit http://tablexi.com/workshops. Guests Sarah Mei (https://twitter.com/sarahmei): Founder of RailsBridge (http://railsbridge.org/), Director of Ruby Central (http://rubycentral.org/), Software Architect at Salesforce (https://www.salesforce.com/). Avdi Grimm (https://twitter.com/avdi): Creator of the RubyTapas Screencast Series (https://www.rubytapas.com/) and author of Exceptional Ruby (http://exceptionalruby.com/) and Confident Ruby (http://www.confidentruby.com/). avdi.codes (https://avdi.codes/). Summary What has changed in web development in the last 20 years, and what do those changes say about the next 20? I recently realized that Avdi Grimm, the head chef of Ruby Tapas, Sarah Mei, of Ruby Central and Salesforce, and I all began our professional careers within a couple of weeks of each other in August 1998. I wanted to talk to them about what’s changed and what’s stayed the same. I was curious as to whether our different career paths led to similar observations. We talk about open source, agile, dynamic languages, distributed systems and how they’ve all changed or haven’t changed the developer’s experience. Notes 02:19 - First Software Job Education and Experiences 09:25 - What has changed? What is easier/harder? 20:16 - What has changed in Product Management? 27:22 - Processor Speed 32:24 - What has stayed the same? 40:20 - Typed Languages 42:48 - What is going to change over the next 5-10 years? - Code Complete: A Practical Handbook of Software Construction by by Steve McConnell (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) Related Episodes Rubyists in Other Languages with James Edward Gray II and Steve Klabnik (https://www.techdoneright.io/43) Ruby Tapas and Avoiding Code with Avdi Grimm (https://www.techdoneright.io/24) Livable Code With Sarah Mei (https://www.techdoneright.io/13) Special Guests: Avdi Grimm and Sarah Mei.

Parent Driven Development Episode 009: Planning Childcare at Conferences 00:25 We're joined by Abby Phoenix (https://twitter.com/aphoenix) today 01:00 When did childcare at Ruby Central events start? started in 2015 and have now been at 6 conferences The intention is to always have childcare at RailsConf (https://railsconf.com/) and RubyConf (https://rubyconf.org/) 03:37 Where to start when you want to have childcare at your conference Treat it as any other vendor Go to the conference venue and ask for recommendations Ask for recommendations from the hotel, local user groups, etc. 6:10 Smaller conferences Smaller conferences are a little more difficult but also easier because if it's in the same location every year you can use the same provider year after year 7:30 Very important that childcare is based in the city of the conference They know how to get around They have alternative options They are on time They have the equipment they need 9:10 How many people use childcare at conferences? Typically 5-7 kids Usually younger children especially since RubyConf and RailsConf are during the school year so most older children are in school Always a question of whether or not a parent can make it work because bringing a child to a conference can be challenging 13:45 Lactation room is also offered Visibility is very important It is important that it is known in the community that childcare and lactation rooms are available at these conferences What to call the lactation room? How it works at a conference to make sure you don't get walking in on and to make sure it is easy The lactation room has outlets and a fridge. 20:20 We tangent about all the things we can't wait to forget as parents Diapers Wiping bums and more 21:30 Lactation rooms are really easy to put in place as a conference organizer 22:20 What have been the biggest challenges of providing childcare at a conference? There were things we did not know to ask when we started and so now we have a list which is helpful Abby goes in to which questions they have started to ask 26:00 What do you wish you could provide? Evening childcare so parents can do things. They will try to work with childcare providers to offer after-hours care but can't provide it themselves 31:00 Childcare is often tailored to 1-5 year olds Most of the participants are younger 32:00 Mandy talks about what you can do with an older child at a conference Is it worth it to bring an older child to a conference? What conferences have a "kids track"? How to engage older kids at conferences? The childcare provider will often tailor childcare towards the age range of the children there 39:30 What are the costs involved for organizers and participants Participants are not charged for using childcare Discussion about costs in different cities 44:00 Genius / Fail moments Allison - My daughter has had a rough few weeks and loves being bounced on a ball but it's tiring for me and hurts my back, so I put her on the ball, tummy down, bounced her, and it calmed her down and she got gas out #Genius Andy - After a difficult day, my daughter wrote "I love you daddy, even when you're grumpy" #Genius? or #Fail? Mandy - My daughter got the principals award for having a positive attitude, was responsible, did homework, and more. I was very proud! #Genius KWu - I'm on call for the week and so I set up a daybed in the office and negotiated with my husband that after the wake-ups, I would go to the office and turn off the monitor and be off duty for a few hours #Genius Abby - My daughters are very picky eaters. My youngest will eat waffles that she'll eat for breakfast. Recently she brought one over to me and said, "mommy I really like these. I like that there is candy inside" #Fail With my oldest, I asked her to describe her perfect meal and I thought she'd talk about candy or ice cream but she said "My perfect meal is a cheese plate" and so from then on every night has been a cheese plate for dinner, which to her means little bits of a variety of food #Genius 54:00 RubyConf is coming! Find more information at @rubyconf (https://twitter.com/rubyconf) and rubyconf.org (https://rubyconf.org/) has some information right now. Registration will open in August or September 54:40 Contact Us! Email us to ask questions. Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com) Support us via Patreon (https://www.patreon.com/parentdrivendev) and get access to our our Slack Community. Panel: Mandy Moore (https://twitter.com/therubyrep) Allison McMillan (https://twitter.com/allie_p) KWu (https://twitter.com/kwu) Andy Croll (https://twitter.com/andycroll) Special Guest: Abby Phoenix.

Organizing Technical Conferences TableXI is now offering training for developers and products teams! For more info, go to http://tablexi.com/workshops (http://tablexi.com/workshops). Get your FREE career growth strategy information and techniques! (https://stickynote.game) Summary I've been attending technical conferences for years, and I've always wondered about the hidden challenges involved in putting a conference together. In this show, four of the best conference organizers I know join me to share their secrets and stories. Marty Haught, organizer of many conferences including RubyConf and RailsConf, Jen Remsik and Jim Remsik, who organize the Madison+ family of conferences, and Leah Silber, who organizes EmberConf and RustConf. Learn about budgets, picking talks, and managing facilities and vendors. Guests Marty Haught (https://twitter.com/mghaught): President at Haught Codeworks (https://haughtcodeworks.com/), Director at Ruby Central (http://rubycentral.org/) organizing RailsConf and RubyConf Jen Remsik (https://twitter.com/jenremsik): Director of People Operations at Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby) Jim Remsik (https://twitter.com/jremsikjr): President of Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby). Leah Silber (https://twitter.com/wifelette): CEO at Tilde Inc. (http://www.tilde.io/). EmberConf (https://emberconf.com/), RustConf (http://rustconf.com/), and RailsConf (https://railsconf.com/) Organizer. Author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven). Notes 03:12 - Getting Things Right and Having Empathy for Attendees 11:16 - Budgetary Aspects 14:53 - Planning Conferences in Other Cities 18:22 - Putting the Program Together and Selection Processes 29:25 - Crafting a Conference Proposal 31:12 - Encouraging and Enabling Attendee Interaction 40:03 - Conference Mentorship 41:26 - Words of Advice Special Guests: Jen Remsik, Jim Resmsik, Leah Silber, and Marty Haught.

Livable Code With Sarah Mei Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), leave us a review on iTunes, and please sign up for our newsletter (http://www.techdoneright.io/newsletter)! Guest Sarah Mei (https://twitter.com/sarahmei): Founder of RailsBridge (http://railsbridge.org/), Director of Ruby Central (http://rubycentral.org/), Chief Consultant at DevMynd Software (https://www.devmynd.com/). Summary Is your code the kind of cluttered house you might find on a reality TV show? Or the kind of sleek, minimalist house you might find in a architectural magazine. Neither one sounds like a place you could comfortably live. Sarah Mei joins the podcast to talk about Livable Code, what makes a codebase livable, how to negotiate tension between junior and senior developers and how Rails deals with developer happiness. Notes 01:33 - What is meant by “Livable Code”? 04:25 - Where does codebase abstraction go wrong? 05:41 - What makes a codebase livable? - Code Climate (https://codeclimate.com/) 09:16 - Calibrating the Right Level for Your Team: Retrospective Meetings 12:22 - Principles of a Codebase 18:21 - Alleviating Tension Between Junior and Senior Developers 22:57 - The Goal of Career Development 26:42 - Guiding Architecture Choices on a Team 30:37 - Does testing help? 34:23 - Programmer Happiness 37:42 - The Attitude Toward JavaScript 39:01 - The Right Design For Your Codebase is Subjective Special Guest: Sarah Mei.

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

Get your Ruby Remote Conf tickets!   02:42 - Nadia Odunayo Introduction Twitter GitHub Ignition Works Nadia Odunayo: Playing Games in the Clouds 05:00 - Ruby Book Club 11:20 - Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 17:23 - Collaboration and Pairing: Guest and Host Roles; Driving and Navigating Coderetreat Ruby DCamp 24:42 - Perspectives and Mapping Sam Livingston-Gray: Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies @ Cascadia Ruby Conf 2014 Cortical Homunculus Peter Gardiner Motor and Sensory Homunculi 41:04 - Ruby Central's Opportunity Scholarship Program Space Babies   Picks   Case Studies in Apprenticeship (Coraline) Everything's an Argument by Andrea A. Lunsford and John J. Ruszkiewicz (Sam) RIF6 Cube 2-inch Mobile Projector (Chuck) Nonviolent Communication: A Language of Life by Marshall B. Rosenberg (Nadia) Robert Frank on Dinner Table Economics (Nadia)   See Also Ruby Rogues Episode #190: Apprenticeship with Joseph Mastey and Jill Lynch of Enova

Get your Ruby Remote Conf tickets!   02:42 - Nadia Odunayo Introduction Twitter GitHub Ignition Works Nadia Odunayo: Playing Games in the Clouds 05:00 - Ruby Book Club 11:20 - Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 17:23 - Collaboration and Pairing: Guest and Host Roles; Driving and Navigating Coderetreat Ruby DCamp 24:42 - Perspectives and Mapping Sam Livingston-Gray: Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies @ Cascadia Ruby Conf 2014 Cortical Homunculus Peter Gardiner Motor and Sensory Homunculi 41:04 - Ruby Central's Opportunity Scholarship Program Space Babies   Picks   Case Studies in Apprenticeship (Coraline) Everything's an Argument by Andrea A. Lunsford and John J. Ruszkiewicz (Sam) RIF6 Cube 2-inch Mobile Projector (Chuck) Nonviolent Communication: A Language of Life by Marshall B. Rosenberg (Nadia) Robert Frank on Dinner Table Economics (Nadia)   See Also Ruby Rogues Episode #190: Apprenticeship with Joseph Mastey and Jill Lynch of Enova

Get your Ruby Remote Conf tickets!   02:42 - Nadia Odunayo Introduction Twitter GitHub Ignition Works Nadia Odunayo: Playing Games in the Clouds 05:00 - Ruby Book Club 11:20 - Nadia Odunayo: The Guest: A Guide To Code Hospitality @ RailsConf 2016 17:23 - Collaboration and Pairing: Guest and Host Roles; Driving and Navigating Coderetreat Ruby DCamp 24:42 - Perspectives and Mapping Sam Livingston-Gray: Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies @ Cascadia Ruby Conf 2014 Cortical Homunculus Peter Gardiner Motor and Sensory Homunculi 41:04 - Ruby Central's Opportunity Scholarship Program Space Babies   Picks   Case Studies in Apprenticeship (Coraline) Everything's an Argument by Andrea A. Lunsford and John J. Ruszkiewicz (Sam) RIF6 Cube 2-inch Mobile Projector (Chuck) Nonviolent Communication: A Language of Life by Marshall B. Rosenberg (Nadia) Robert Frank on Dinner Table Economics (Nadia)   See Also Ruby Rogues Episode #190: Apprenticeship with Joseph Mastey and Jill Lynch of Enova

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

02:05 - André Arko Introduction + Bundler Twitter GitHub Blog 04:28 - Ruby Together Trade Association ​Brian Mikulencak 10:52 - Ruby Central 501(c) Organization 14:23 - Ruby Together Timeline 16:01 - Open Source People Depend on vs Open Source as a Hobby 17:03 - Corporate Member Rights / The Structure of Ruby Together Monthly Contributions 20:19 - How the Board Makes Decisions Slack 23:00 - Membership Numbers 24:03 - How Voting Works 26:58 - How much work is involved in maintaining these projects? 30:08 - How is work doled out? Eric Hodel (@drbrain) Aaron Patterson (@tenderlove) 33:41 - Future Plans and Community Impact Fastly 40:28 - Getting People Involved 43:34 - Lessons Learned 45:23 - Code of Conducts / Community Values Picks Boundaries: A talk by Gary Bernhardt from SCNA 2012 (André) The Protomen (André) Bubblesort Zines (André) Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug (Saron) F.lux (Saron) Hue (Saron) Madison Ruby Day 1 (Coraline) Madison Ruby Day 2 (Coraline) Survive Escape From Atlantis 30th Anniversary Edition (Coraline) Angular Remote Conf (Chuck) React Rally (Chuck) Alcatraz Books by Brandon Sanderson (Chuck)

Marty Haught, director of Ruby Central, the non-profit that organizes Rails Conf and Ruby Conf has read and reviewed over 1,000 talk proposals, and organize several regional and national conferences for developers. We talk about how to write a great talk proposal, how to make conferences a welcome and inclusive space for all developers, and how to prepare for your next big talk. Show Links Digital Ocean (sponsor) MongoDB (sponsor) Heroku (sponsor) TwilioQuest (sponsor) Codeland Conf Codeland 2019

The Rogues talk to Evan Phoenix and Chad Fowler about Ruby Central.

The Rogues talk to Evan Phoenix and Chad Fowler about Ruby Central.

The Rogues talk to Evan Phoenix and Chad Fowler about Ruby Central.

In this episode, Chad discusses how he broke out of a comfortable job as a forklift operator, which ultimately led to him becoming a programmer. He discusses his job, Ruby Central, and the Pragmatic Studio as contributions he makes to the community. We also discuss the ebb and flow of passion for programming and how to avoid burnout on the things that we love. He has actually put a ban on himself for travel so he can spend time on the things that are important. Chad told me that he espouses the Test Driven Development mindset, Continuous Integration, and Agile or dynamic methodologies. We discuss task automation, Puppet, Chef, etc. The important things in software development boil down to quality. If you can automate your common, important tasks and make it easy for the person who needs it to kick off the process on their own. Chad also had some great suggestions for new developers. First, read code. Second, write tests for the areas of code that don't have tests. This will force you to refactor the code and make it better. To get involved in the community, you can start or organize a conference, create open source projects, help software maintainers meet Ruby 1.9 compatibility issues, join a mailing list, and so much more… Download this Episode