The Ruby Gems Podcast
A Ruby Central podcast that takes an inside look at the people, projects, and progress shaping the Ruby community. Discover the gems in Ruby and connect to this vibrant group of amazing people.
The Ruby Gems Podcast
Sarah Mei: RailsBridge, Community Building, and the Human Side of Code
Sarah Mei, a longtime Ruby community leader and former Ruby Central board member, shares her journey from co-founding RailsBridge to advocating for diversity and human-centered software development.
• Co-founded RailsBridge in 2009 to help thousands from underrepresented backgrounds enter tech
• Reflects on the evolution of RailsConf and Ruby Central's future focus on Ruby
• Shares memories of the early internet era before "the internet had cats"
• Explains how representation and diversity at conferences influenced her journey
• Discusses how code design should be contextual, evolving, and focused on clarity
• Describes the connection between team communication patterns and code quality
• Explores why people, not code, are the most valuable asset in software development
• Compares AI programming assistance to the transition to garbage collection in the 90s
• Celebrates the resurgence of local Ruby meetups and community events
Welcome to the Ruby Gems podcast brought to you by Ruby Central, where we uncover the stories behind the code. We're your hosts.
David Hill:I'm David Hill
Marty Haught:and I'm Marty Haught. Before we introduce today's guests, I wanted to pause for a moment to kind of talk about the episodes we've put together so far. The first two have been really a dive into Ruby Central and its history, as well as touching on RailsConf, which we just had two weeks ago as the final RailsConf, and so in today's episode we're going to do some more reflecting on this, but in future episodes we're going to move on to other interesting things in the Ruby community.
David Hill:And so today's guest we're joined by Sarah Mei. Welcome to the podcast, Sarah. Thanks for having me. So Sarah is a longtime leader in the Ruby community, known not only for her technical expertise but also for her work advocating for inclusion and empathy in software development. She was a Ruby Central board member from 2014 to 2019, where she helped organize RailsConf and RubyConf. She co-founded RailsBridge, an organization that has helped thousands of people from underrepresented backgrounds get started in tech, and she's been a powerful voice on topics like code design, team dynamics and the human side of programming. Sarah's impact reaches far beyond Ruby, but her roots in this community have run really deep and we're excited to dive into her story today. So, Sarah, when we were chatting at RailsConf, at one point you said something along the lines of it's been five years since I have given a new talk or done anything like this at a conference, so I just kind of wanted to start you off by asking how did it feel to be back up on the stage and be doing that again?
Sarah Mei:It was fun. Part of the reason I did all those talks back in, say, maybe the 2010s were the era in which I did the most of my talks. It was fun to put together a talk, it was fun to deliver it and get people's reactions and I think Avdi Grimm said this once but the best way to be an introvert at a conference is to do a talk, because then people will come up to you and talk to you about the thing that you find interesting. So I really took that and ran with it and it's been invaluable for me as part of my career development and since we chatted, I have committed to putting together a new talk, by the way, that I'm going to premiere at the SF Ruby conference.
David Hill:Nice, okay, that's exciting. I don't remember who I heard that bit of wisdom from, but the one time I've given a talk so far at a conference, I felt that exact same thing, that revelation of oh, all of that energy I have to put into trying to go talk to people becomes irrelevant because people are coming up and talking to me.
Sarah Mei:This is great, it's the best introvert hack ever.
David Hill:So at RailsConf that we just had, were there any presentations or talks that you attended that were particularly memorable for you?
Sarah Mei:No, I spent a lot of time in the hallway track so I'm sure I missed some of the great talks track, so I'm sure I missed some of the great talks.
Sarah Mei:One talk that I did find very thought provoking was Marco Roth's talk about the future of the front end in Rails, which is something that I feel like has never been completely settled. I guess maybe it's just it feels like the MVC part of Rails and the models and the controllers have always felt very. This is how we do it and there's not been a lot of changes over the years. The Vue layer has had a lot of changes over the years and I appreciated his insights into what we could do, what we could draw from other communities. Specifically, he is thinking about the Vue layer that Elixir has. I think of it as a Rails heritage community because it was started by Jose Valim, who, of course, was a Rails core member at one point, and it had a lot in common with Rails, and so I think of it as part of the Rails diaspora and I think it's really interesting to look at those projects and be like what could we bring back into Rails?
David Hill:Nice. Yeah, I really liked Marco's talk and a lot of the examples that he pulled up, Like, yeah, there's all these things that we could be doing better to have better tooling and better experience writing the code. And since so much of Ruby, like the heritage of Ruby, was it being built towards? Developer happiness and productivity is like, oh yeah, maybe we should be talking about that more.
Sarah Mei:Oh yeah, maybe we should be talking about that more. Yeah, I mean, I think Rails was built with a lot of the same messages in mind, right? I think if you look at David's Oops, I Build a Blog video, it's got that energy. It's like, oh, look at all the stuff it'll do for you. So easy for you to do your creative projects now.
David Hill:So with this chapter of Ruby Central done and RailsConf kind of concluded, do you have any thoughts on where the organization or the community goes from here?
Sarah Mei:I'm actually kind of excited. I'm sad also that the RailsConf chapter is coming to an end, but at the same time I am excited to have an organization that is just focused on Ruby. I am excited to see what RubyConf becomes. I think it could be with only having one conference to focus on during the year. They could expand the types of talks that happen at RubyConf. We could really make it more of a first-class citizen. I mean not that it ever, but RailsConf was the commercial conference, right, it was the one with the big sponsors, the booths, the what have you, and so RubyConf always felt like a smaller kind of more specialist kind of conference and I think it would be interesting to see where they go with that and also with the renewed focus on open source or RubyGems. I think that that is also a really important thing for us as a community, you know, be able to understand and support all of this infrastructure that we all depend on every day.
Marty Haught:Sarah, I kind of want to change topics and you know you and I both got started in tech back in the nineties and I'd love to hear your thoughts on what it was like back then and sort of how that progressed over the next decade or so.
Sarah Mei:Yeah, interesting story there. I was talking to Aaron Patterson at RailsConf and he looked at bios of you that you've given to various conferences over the years and he said one of the bios was I've been on the internet since before. It had cats. He's like what does that even mean? And I was like before there were graphic it was text news groups and you could access the worldwide web with a text-based thing in your terminal and, like there were no images, you could get images from some of the news groups if you were really dedicated and wanted to do it.
Sarah Mei:But yeah, cat pictures were not really a thing until later and I thought wow, yeah, that is a long time ago, it was that before the internet had cats.
Sarah Mei:You know, it was a very academic kind of community when I got started in, I'd say, 93, 94. And it was an interesting community. It was extremely I always felt out of place as a woman in that space, especially in news groups and mailing lists and things like that, where occasionally I would just use a male name to ask a question because otherwise no one would just Wow, wow, like on mailing groups for libraries and stuff right yeah.
Sarah Mei:Then everyone would just wow, like on mailing groups for, like libraries and stuff right like if I use my, then everyone would just kind of ignore it or point me at the super basic resources that of course I had already read, and they would only actually answer the question if I use the mail name. So there are some ways in which I am glad that era of the internet is over. But one thing that was great about that time was that there was so much optimism about the web and what it could do for society. My cousin, who lives in the middle of nowhere in eastern Washington with not even a community college within a hundred mile radius, could access an education. That was just something that you couldn't do right, it was just not possible. Like there were correspondence courses and things like that, but in terms of like actually accessing things from real universities and learning on your own terms, that was something that people were really excited about, kind of raising the educational bar.
Sarah Mei:I think also everyone was very excited about the prospect of the web helping folks find their tribe in ways that might not work locally, physically, in real life, especially for groups like the LGBTQ community, where in a lot of places there was no in-person community of any sort, where in a lot of places there was no in-person community of any sort, and the internet really gave folks an opportunity to find people that are similar to them, and so there's a lot of optimism that the web was going to be good for society and fast forward 25 years, and sometimes it feels like that promise was never really delivered, and I'm excited about a lot of things going on in the tech industry today, but one of the things I miss maybe about that time was like just felt more optimistic, and that may have had to do with how old I was at the time as well, but yeah, I felt it from a lot of different places at that time, and that's the thing that I feel like is most different, apart from everything else.
Marty Haught:Yeah, yeah, I mean there's a lot of positive things still, but there's so much negative and it's difficult to avoid it.
Sarah Mei:Yeah, one of the great paradoxes, I feel like, is that the internet allowed folks to find their tribe, but that's as true for folks on the far-right fascism spectrum as it is for folks that aren't in that area and folks from the LGBTQ community, and something I think about a lot.
Marty Haught:I want to move on to RailsBridge Now. I don't recall, Sarah, when we first met. It was quite a while ago. I remember chatting with you, at least in 2009. And I invited you and Sarah Allen to host a RailsBridge workshop at Rocky Mountain Ruby, 2010. I wonder if you could tell us about RailsBridge and share its origin story.
Sarah Mei:Well, maybe not many people know this, but its origin story was in RubyDrama. I don't remember exactly what the incident was that provoked it, but there was a group of us that all got together that were interested in doing different things to help with diversity in the Ruby and rails community. Initially there were lots of different efforts, including Sarah Allen's and my efforts around workshops, and then a lot of the other things dropped away or people got busy or what have you, and it turns out that the workshops were the thing that emerged from that organization and we did the first one in 2009. Now our thought here was if we can show people at the time we were focused on women if we can show women that they can program, that it's not some mythical thing where you need to have a math degree and understand super abstract reasoning that it can be a very concrete, productive and interesting way to work, then if even one in a hundred joins the Rails community, that's perfect, right? Like if one person out of every workshop decides to join the Rails community, or maybe even just one person out of every other workshop gets a numbers game, it's going to increase. That was our motivation. We need to reach a lot of people because we don't know which ones are interested or will stay, and it was also a way for us to help people in the San Francisco local Ruby community to teach also right, we wanted to help them learn how to talk about what they love to do. That was not necessarily a value amongst many software teams at the time and we wanted to help them learn how to teach how to work with folks that were more junior than they are, how to explain these basic concepts Like what is a variable? Yeah Right, what is a variable? How would you explain that to someone who's not a programmer? And the whole experience. It just been so amazing for me. Sarah Allen was really the one who moved it forward from, like, a logistics perspective, who, like, found us companies that were willing to host and dealt with food and budgets and things like that. What I did was I wrote the curriculum and I was initially the teacher of the first one we did, and sarah allen also taught many of the workshops.
Sarah Mei:The way we set it up. It was like friday night you come in and you bring your laptop and we will help you set up ruby and rails on your laptop and then come back on saturday and we'll do the actual workshop. And we did that because the most frustrating part of starting out in rails is getting ruby and rails installed on your laptop. There are a million different ways it can go wrong, especially on windows. I think for a while I was probably the person in the world that knew the most about how to get Ruby and Rails installed on a Windows computer. A lot of people start up with Windows computers and we needed to be able to support that. It can't be like oh, you have to have a Mac in order to take this workshop. Also, it gave us time to reset, because it was a frustrating experience usually no matter what kind of computer they had.
Sarah Mei:It was often a very frustrating experience, and so having that pause between friday night and saturday morning allowed us to kind of leave that in the dust and move forward in a more positive mindset on saturday. And so then we would do a workshop that was most of the day on saturday, and then we would go out to a restaurant or a bar. Everyone gets a ticket. Let's socialize both the teachers and the students, and that was also important for us. Like we wanted to make sure that folks felt not only that they could do programming though that was a thing that they could approach but also that they knew somebody in Ruby community. So if they came to a meetup like, they would already know a few people, right. So the socialization is also an important part of this, and we started this really just as a way to get more women into the San Francisco Ruby community. And then a lot of people like yourself you were one of the earliest that were interested in this in terms of doing something like it at a conference, where you bring in folks that are new maybe not new to programming often, but are new to Ruby, new to the community and run this workshop for them and then they go to the conference the next day kind of deal, and I think that, like that, worked really well. We did that at a number of different conferences in that time period and it was a fun way for me to start to get to know conference organizers and other speakers and things like that, even before I was doing a lot of speaking and then we had a lot of folks that picked up from there, right Like we had a lot of folks that did chapters in their own communities.
Sarah Mei:They rewrote the curriculum, they did everything different. Like it's fine, we just wanted to be able to support all of these different efforts that people that were kind of similar. A lot of different organizations kind of came out of rails bridge. There was one for python, there was one for javascript, black girls code came out of it, rails girls came out of it. There's a lot of history there, different groups coming through a rails bridge workshop and then sort of breaking out and doing something very similar for their own community, which I think is also amazing. Maybe one of the things I'm most proud about around the RailsBridge experience and since the pandemic, a big part of our workshops was always that they were in-person that you would get to know people in your local community, and pandemic really shut a lot of that down. I don't think either me or Sarah Allen have had the bandwidth to think about reviving it. No-transcript, and I'd rather do that than try and resurrect the thing that I used to do.
David Hill:Speaking of those types of diversity efforts and the things that you used to do, like you've been talking about kind of spearheading some of these diversity efforts as a big focus of what you did for a while, In our kind of pre-chat before we started recording, you mentioned a couple of things that were things that maybe you kind of championed when you were on the board for Ruby Central. Could you talk a little bit more about those and why you thought those were important?
Sarah Mei:By the time I joined the board they had already adopted a code of conduct and they had already started the guides and scholars program, which of course already started. And that was part of the reason that I felt like I wanted to be involved at all in the first place, because they were trying right, they were making material efforts in the direction of diversifying the community care at the rails bridge workshops and it really was just kind of a play group, right. We hired a babysitter and they took a conference room with a bunch of legos maybe and some baby toys and, like you know, kept the kids busy while the moms were doing this workshop. And you know, at the time I had young kids. I think a lot of people in the san francisco ruby community still remember one workshop we did in san francisco where my kids came and my daughter was like four and a half, my son was still in diapers and now my son is 16 and my daughter is 20.
Sarah Mei:So it's been a long time, but having young kids is often the busiest time in a parent's life, in a parent's life. Once they're able to sort of be on their own a little bit more and start making some of their own decisions. It feels like the intensity of parenting is still there at times, but maybe less often, and I wanted to make sure that folks that were in that situation didn't necessarily have to choose between their family and career advancement. This was important for me because if I talk to people in the Ruby community, generally speaking, most of their kids are much younger than mine, and so I just wanted to make sure that people in that stage of their life could, even if they didn't have a partner that was very supportive, could still advance their career and do these interesting things. I think similar efforts like patient rooms, other diversity markers such as gender neutral bathrooms and things like that, I think were important, and I feel like today those are table stakes for conferences, which I think says a lot about how much progress we've made.
Marty Haught:I think one of the things there that was really touching for me at the final RailsConf was Aji Slater did a keynote of keynotes on the final day and a lot of their material they covered. It really struck home how they noticed what we were trying to do behind the scenes and how it had impact and especially around keynote speaker selection and sort of the intentionality that we had as a group around the representation we put on stage and the messaging that we thought about when we were picking out speakers. I'm wondering if there's sort of any thoughts you have or reflections on that, since you were part of that process with us.
Sarah Mei:Yeah, looking back, I think representation is very important. I remember when I went to the first RailsConf in 2006, there was only one woman doing a talk, and it was Amy Hoy and I went to the talk even though I had no idea what she was talking about.
Sarah Mei:I was very new to Ruby on Rails at that point and it just went. You know 99% of it went way over my head, but it was so encouraging to see her up there and to see people. Speakers are kind of the rock stars of a conference, almost right. They're the folks that everyone looks up to and like maybe it's like, wow, that's cool. I would love to do that one day, maybe. Or I don't want to do that, but these people like know a lot of useful things. That's cool. And so you know, literally everybody else at the conference was on stage, was male, including all the organizers and so forth and right, and just seeing her up there was really like, okay, maybe I could do this, maybe I could do talks, maybe I could be part of this community.
Sarah Mei:When you are running these premier conferences that speak for a whole technical community, it is really important to show that lots of different types of people can do this work and can be experts and can have information and insight to share with other people that do this work.
Sarah Mei:And it's really hard sometimes to find folks that will be more representative to be on stage just because it is.
Sarah Mei:If you're the first one of any particular demographic, like it's always hard. It's always more hard than it is if there are already other people in there. When I started my career as a programmer in the 90s, I was always the first and only woman on the team, until 2005. And after that point I realized, oh, it's not fun to be the first one, and maybe I don't have to like, maybe I can now start looking for jobs where I do work with other engineers that aren't in the demographic majority, and so I think one of the things that was important to me when I was on the board was this type of demonstrating that, like, there are a lot of different people that have insights into the work that we do. It's important to hear from them, even for folks that aren't in that particular demographic. It's important for them to see that like, yeah, people that don't look like me can also be experts and have insights that are valuable to me well said.
David Hill:It's one of those frustrating parts about humanity sometimes, I guess, is that we get so comfortable just seeing and interacting with people who look and think and act like we do that we forget that having that diversity of not even just appearance, but that diversity of thought and that diversity of experience can revolutionize the way we approach problems, just because there's avenues of thought and consideration that we haven't, just because there's avenues of thought and consideration that we haven't taken into account, that someone from an outside perspective can bring in. And yeah, that's just so ridiculously important and it feels like we as a species lose track of that way too often. But back to our questions. So, like we talked about in your intro at the beginning of the episode, there are these three topics that you've been especially vocal about over your career. I kind of wanted to take them one at a time and if you could offer some thoughts about why those were important and why you feel so strongly about them. The first one is code design.
Sarah Mei:Software design has been something I've always been interested in, from the beginning of my career, because it seemed so cool. It was like oh, I get to decide how my code is going to be organized For me, I like to organize things. This is how code feels to me. I know some people that feels like solving a puzzle or it feels like writing an essay. For me, it feels like organizing things and that's what I love about it. But as I got into the industry, one of the things I realized is that design often can get in your way. It actually obscures understanding and that just because it fits some pattern in a book, if it obscures understanding, it's not good design. And I had this contradiction in my head for a long time. That, like, design feels important, but the design that I have worked with as a junior developer wasn't useful to me. There was some point at which I realized oh, if you design for the people that are working on your code base, you're going to be better off. Be better off. And if you have a code base that's a bunch of super senior people and you're not expecting to ever have junior developers work on it, then a very abstracted and code base that needs a lot of time to like. Ramp up on can be useful, can be good design in that case, right. But if you've got, I think, what is the more typical case, which is a code base that's worked on by folks at multiple experience levels I've obviously been in San Francisco and Silicon Valley where turnover has been quite high during certain parts of my career, and so you never really know you need to be able to build a code base that can survive somebody leaving and a new person coming in, leaving and a new person coming in. And my thoughts around what is good design have really changed, and these days I think good design is contextual and it's never really even settled right, like you can put something into what feels like a useful design where everyone can access it, everyone can sort of drop in and understand it, and then you'll have performance problems in that area and then suddenly it's not a good design because you need to figure out how to make it work faster, and so I think it's an ever-changing thing. It's not so much of a static thing like I thought it was in the beginning. This is how I categorize my code I'm going to put this type of code here, that type of code there, and then I'm done with the design phase quote-unquote design phase that type of code there, and then I'm done with the design phase quote-unquote design phase and I can move on to the quote-unquote implementation phase, where I just fill out all of these buckets that I have organized.
Sarah Mei:And you know what? That never worked. Yeah, people kept telling me it worked and it never worked for me because I would get into it and I realized I have the wrong buckets. Sometimes it was the slightly wrong bucket, sometimes it was the completely wrong buckets, sometimes it was the completely wrong buckets. And as I get into it and I understand the problem better, then I know what buckets to sort of move towards. And that was where I started to gain this understanding around design as being like a process and not like an ongoing process that needs to happen in parallel with implementation and it can't be like a phase, because you just don't understand the problem well until you get in there and you write the code that makes it do it.
David Hill:That has always been a problem I've had in every kind of project planning meeting I've ever gone into, especially with the whole idea of making estimates for how long it'll take to build something. And then, like the moment I get into actually trying to build something, it's like oh, none of the meetings we had considered any of the issues I just discovered by going in and starting to try to implement something we didn't take into account any of these problems. I just discovered oh, what do I do now?
Marty Haught:It's frustrating, but at the same time I was like, oh, I'm not the only one who had that problem, yay, and you know what's interesting is, back in the 90s there was this pattern where you'd have a bunch of business analysts come up with all the requirements and they would spend months documenting it. It'd be like 30 or 40 pages of this stuff. Then a software architect would figure out the whole design and then they would say here's all your classes and all your methods with their signatures. Just go implement this. This is what I walked into it. You can imagine how that goes. And then testing is something you do later on, when it's all done, and then you integrate and you ship.
Sarah Mei:You've got separate people. Yeah, they're separate.
Marty Haught:Oh, they're separate people. Of course it's a separate department, right.
Sarah Mei:Developers don't test. Wow, they waste their time. That was a long time ago it was Well.
David Hill:Thankfully, certain aspects have improved over time. So that was code design, and you kind of touched on this next topic a little bit in terms of why code design was important. Felt like that dovetails nicely into team dynamics.
Sarah Mei:Next, yeah, of course there's the old law, right, that your software will resemble your communication structure that is used to build it, and I learned about that, like in college. That was one of the things that, like within my software design courses, made a lot of sense to me. But I'm not sure I really understood it until maybe 10 years or 15 years into my career when I started to realize that your code base is literally a reflection of your team and how well it communicates. And when I say literally, I mean like, let's say that you've got a code base and you've got three different people working on it, and they're working on three different parts of the code. All of those three parts are going to look completely different in some cases. Right, they're going to be designed differently. They're going to have different values in terms of what they think is good code, and then they're going to come together at some point and they're going to figure out how they communicate, which is sort of the old way of doing it. Right, like, I'm going to work on my code, you're going to be working on your code, and then, once we're done, we will have a meeting at which we figure out how my code is going to send information to your code and vice versa. And that's what it's easy to see, I think, when people are islands and you're not communicating well and you end up in a situation where you have different expectations about what kind of data you're sending and consuming with the other people, because you just didn't talk to them enough about what they were encountering as they implemented it.
Sarah Mei:But I think it's as true as that, even when it's a code base that is more communally owned, such as like in a startup, for example, where you often have a number of people working on a code base and they're just all in there fixing what needs to be fixed, adding what needs to be added, without necessarily specializing, because then you start to see it where, if people don't communicate well enough, you start to get spaghetti code, you start to get the files that no one wants to open, you start to get the big ball of mud problem, where your software design turns into a big ball of mud. Yeah, and that can happen very quickly. Ask me how I know. But I think it's important to pay attention to how well you are communicating with the other people on your team. It's important to pay attention to how well you are communicating with the other people on your team. If it's important to you that the code base stay usable, that the code base stay workable and able to be changed in the way you need it to be, then how you communicate with the rest of your team is really important. And if you are not communicating well, if there's one person who's kind of a jerk and everyone avoids them, or if there's clicks where two people really get along and two other people really get along but they don't really like each other, you can see that in the code and muddy communication leads to muddy code and this is why I think it's so important.
Sarah Mei:For a long time, the culture around software development was that it's an extremely individual skill.
Sarah Mei:If you're good at it, you come up with good code.
Sarah Mei:If you're bad at it, come up with bad code.
Sarah Mei:But I think part of what we've realized maybe as an industry a little bit, is that it's not an individual game.
Sarah Mei:It's absolutely a team game and you have to be working and changing your work and adjusting your work alongside all of the other people that are working on the code with you. Of course, we've seen like extreme manifestations of this, like pair programming, which is something that I advocate for a lot and do, which is where you are literally talking to somebody to write your code. I found that it was extremely helpful for me because it helped me learn how to talk about what's in my head, rather than before that it was often difficult for me to explain to somebody why I wanted code to be the way I wanted it to be, and it helps me understand and sometimes even see realize that the reasons I have are actually not that valid. They're like the reason I want. This is 100% an aesthetic choice and like it doesn't really matter, and I think that the team dynamics are just super important in a software team and the closer communication you can have with other people on the team, the better your code's going to be.
David Hill:The closer communication you can have with other people on the team, the better your code's going to be. That kind of overlaps probably significantly with the third bullet point of just like the human side of programming. Like you've been talking about all of the Team Dynamics stuff like that, very much is the human side of programming, but is there anything else you'd like to add to that particular?
Sarah Mei:bullet point. I think this is a little bit maybe slightly of a different topic in my head anyway, and this is about the fact that the code is not the most important thing on the team, that the code people well, especially like maybe at large companies consider the code to be their intellectual property, like that is the thing that needs to be protected at all costs, where the value is.
Sarah Mei:Where the value is, and that's the value that the company creates, is literally the code Right? But I don't believe that that's true. I think the value lies in the people who have the problem in their brain that you're trying to solve. The code is a messy translation of that problem. And if you switched out the team entirely, like, let's say, you bought a short form communication company and then fired all of their actual engineers and brought in engineers from your electric car company, that never happened. That's never happened.
Sarah Mei:But, like you know, just stay with me here theoretically okay, the people that are coming from the outside don't have that problem in their brain. They've been thinking about completely different problems, like they may be good programmers for the type of thing that they do, but they come in and they have to reconstruct the problem in their head. People that have that knowledge are way more valuable than the code itself, because they could remake the code If Git's decentralized. But let's say that Git fails us someday and all of our code disappears for a project. Or let's say your Perforce fails. If you've still got the people that understand the problems, that is a big problem, but it's not a company-ending problem.
Marty Haught:Yeah, interesting. So, sarah, I saw you returned to writing recently. What are you thinking?
Sarah Mei:about these days.
Marty Haught:Yeah.
Sarah Mei:One of the things I've been thinking a lot about recently is what's changing about how we build software these days, because you know, as we've already kind of discussed here, it's changed a lot. How we build software has changed a lot in the last 25 years. It changed a lot in the last 25 years. Before that. The experience of being a programmer these days is just 100% different from being a programmer in the 60s, like there's almost no overlap.
Sarah Mei:So one of the things I've been thinking about is I came into this industry and maybe sort of hit my stride at a time when things are at a certain point and now they're continuing to move, obviously, and so one of the things I thought about is around this idea of coding assistance from quote-unquote AI is from generative AI, basically. And one of the things that I'm interested in there is how is this going to change how we build software? And I don't think we need to be afraid of this type of thing. I don't think it's going to replace junior developers. I don't think it's going to replace junior developers. I don't think it's going to replace any developers. I think in the short term, some of the business people think it will right but in reality that's not going to happen because it's just.
Sarah Mei:To me it feels like another abstraction and the reactions that I see in the community right now feel a lot like something that happened early in my career, which is the replacement of individual memory management with garbage collection. When Java first came out in the 90s, people very respected, very good programmers in the industry said this is only a toy. There's no way. There is no way you can ever run anything on production that uses a virtual machine, because in order to get the performance you need, you need be able to hand fear in that memory. And what I felt at the time and maybe didn't realize it, but looking back now I realize it is fear, fear of irrelevance. Now they had spent a lot of time working on this skill of memory management, which was quite difficult.
Sarah Mei:All of my college classes are in C. My first job was in C. This is the thing I was expecting to do and it's quite difficult. And all these people that spent 20 years really getting good at it were afraid that they were suddenly irrelevant, that their skills were irrelevant, that they were never going to be able to get work again. And so from that place of fear, come these, come these. These messages about this will never amount to anything. And java took over the world, right? You can run anything on java. These days, java is considered the fast web substrate, especially compared to rails, right?
Sarah Mei:yeah this is something that that the JRuby folks have been on about for the last 15 years, and no one really thinks about going back and managing their own memory. I mean, I think there are specialized programming areas where that still happens. Like I would say hardware, I would say any kind of very constrained device, but when we're talking about building web applications, yeah, nobody does that anymore. And yet we have. Since that transformation happens call it like late 90s, early 2000s all of a sudden, we have been able to build more things. We've been able to build bigger things. We took the brain space that had been taken up by hand managing your memory and we used it to make more ambitious things.
Sarah Mei:I don't think it's a coincidence that, like after this transformation happened, that's when we got the cloud, that's when we got the beginnings of all of these juggernauts that you see today, like google, facebook. All of these things were made possible by the fact that you can do more as a programmer than you used to be able to and by the fact that it made programming more accessible. You had a whole new generation of programmers that never learned how to manage their own memory, and it doesn't matter, they don't need that skill, you know, and it opened up programming to a whole new class of people. I don't think we would have had boot camps or any of these types of arrangements where you don't have to have a cs degree to be part of this industry, if that change hadn't happened, and so it enabled the tech industry to really make much bigger strides. I feel like that is a direction that AI could go as well AI assistance anyway, this idea that there's less that I need to do and I can put my brainpower to more creative problems, and it might make programming more accessible to more people, and that is never a bad thing.
Sarah Mei:I mean, I think people like product managers shouldn't be coding things up, but like, if they can, isn't that a plus? Isn't that a good thing that they can be a little bit more sympathetic about what the developers are doing, whether or not they build things that go into production? You know, having your product managers have at least some experience with code often provokes empathy, better empathy between the teams, and I'm even thinking about this fact that, like, maybe software design is irrelevant, this thing that I have spent so much of my career thinking about and writing about and doing talks about. Maybe it's going to be irrelevant, because maybe when we have our assistants who are organizing things in a way that they can understand, like in the way that the AI can understand, right, maybe it matters less whether the humans can understand it, and I don't know how that manifests or how that will manifest or if it will at all. But yeah, it's one of those things where I experienced some of that fear.
Sarah Mei:I'm like, oh, I spent all this time working on software design, helping people understand it. Maybe all of that's going to be irrelevant, right, what I'm trying to do is lean into that fear and think about what could that enable? What could that enable in a new generation of programmers? What could that mean for our industry? And how can I live with this fear but push through it as well and continue to add value to the industry? It's almost like it's the human part of AI and how it will enable us to do things. I'm less concerned about the technology of AI, although I have a lot of, like, ethical and energy concerns but more about, like, how it's going to change how we, as programmers, do our jobs.
David Hill:My daughter has some very rabid opinions about the ethical use of AI, especially since she's in an artistic field, and so there's a lot of open questions that we have there but it's not just programmers that are feeling that fear, it's writers, it's artists, and I'm not sure if it's a positive effect in programming.
Sarah Mei:I'm not expecting it to be a positive effect in every area that it tries to touch. There's a lot to see and to figure out as we go along here, not least of which can one of these companies actually make money and provide a product?
David Hill:Going back to RailsConf for a bit, one of my now favorite parts of the Ruby Central Conferences is Ruby Karaoke, and I had my very first experience with it at RubyConf in November, and you were there for both of my Ruby Karaoke experiences, and so I just kind of wanted to ask you what your thoughts about Ruby Karaoke and why you go to that event, because I find it a lot of fun. I just wanted to see what you have to say about it.
Sarah Mei:Ruby Karaoke has been a thing at a lot of conferences. I've been to Most of them. It's been like a very collective thing rather than it's like one person stands up and sings a thing. It's like we all kind of sing it together and we learn about what people's favorite songs are, what people's favorite artists are. It's a different kind of conversation than you have with people in the hallway track and you get to know people better. And I think for me it's always a chance to get to know a different group of people.
Sarah Mei:I usually end up in a room with a bunch of people I don't know haven't met right right, which sometimes feels difficult to do at the conference, because there's so many people that I know that I want to say hi to that I want to like catch up with. Sometimes it feels like it's hard for me to like meet new people at the conference, which I want to do. And so ruby karaoke, I think, has been like a critical. You know it sounds like it's like all strategy and whatever. But one of the things I've realized is like if I do things that feel fun, then I can kind of figure out why later, right, and so that's one of the things that I thought with Ruby karaoke is like.
David Hill:I really enjoy this and I think it's the feeling of collective creation Marty's, kind of given me the flag that maybe we need towards our wrap-up segment. We've, uh, some kind of quick fire. We'll call it the ruby roundup questions to cap things off. So our first question is what's your go-to comfort food?
Sarah Mei:oh, it's got to be french fries classic. I like a french fry. It doesn't matter where it comes from, they're all good how do you eat them?
Marty Haught:Do you have a condiment of choice? Do you have them spicy? Do you have them curly? Q, just salt. Salt is my favorite, I love salt.
Sarah Mei:But I do like mayonnaise, actually with my fries, and I also like mayonnaise mixed with ketchup.
David Hill:Or, as they call it in, utah, fry sauce that's where I was introduced to that particular, add a little pickle juice in there.
Marty Haught:Yeah, okay, are you reading anything for fun right now?
Sarah Mei:I am reading a book about birds. I have maybe become a bird person maybe not as much as other bird people, but I started noticing the birds that are in my backyard and birds that I see when I'm out and about, and I live in the middle of a national park, so there's a lot of birds around me and perfect. So, yeah, I'm learning about birds and the ancestry of birds, all the different types of birds, also the history of birding as a hobby, I guess.
Sarah Mei:Yeah, or as a thing that people do and I'm not sure I'm ready to be like a goes out at 5 am and sits in a thicket to like see the fancy bird kind of person, but I am enjoying noticing birds in my backyard.
David Hill:Nice. Are there any recent movies or TV shows that really hit home for you?
Sarah Mei:for some reason, I've really enjoyed sports documentaries. Now, I'm not a sports person at all, I don't really play sports, I don't really watch sports that much, but I have gotten interested in how elite sports people live because it's so weird. It is so strange and there's a number of documentary series about like there's one about the tour de france, there's one about f1, there's one about basketball, there's one about different positions in american football, like receivers and quarterbacks and stuff like that. I don't know why, but I've been really enjoying all those things, even though I'm not a sports person, because I feel like it makes the sports people people and not just dots on a screen that are moving around.
Marty Haught:What's got you excited in tech right now?
Sarah Mei:Let me say the Ruby community right now is that we're seeing a resurgence of local meetups and conferences that kind of went dormant, call it the late 2010s, and then through the pandemic and hasn't ever really picked up. We've got rocky mountain ruby coming up, this sf ruby conference, which has grown out of the sf ruby meetup. The woman who runs it arena decided one day that she thought there should be a san francisco ruby meetup again, and so now we have a san francisco ruby meetup again, yeah, and now we have the conference again. I see a lot of that happening and it's very heartening to me to see that happening, because it's the local community that's always been the best part for me about our community.
David Hill:And finally, what's a favorite Ruby gem, preferably not one of the super well-known ones.
Sarah Mei:Honestly, I think the one that has really been part of my work life and part of my career for the longest time is Rails. Sorry, it's not obscure, but this has been the biggest influence on how I think about software, how I think about people, how I think about communities. I came from the Java world and before that from the C world, and there's just nothing like it, and Ruby by itself was always really interesting, but Rails is what made it possible for me to build a career on top of Ruby, and so I feel like that's the one that, for me, is always going to be my favorite gem.
Marty Haught:All right, Sarah. One more question when can people find you on the internet?
Sarah Mei:Well, I have a sub stack. I used to be a lot on Twitter, but I have not really taken to any of the other short form communication platforms. Part of the reason I'm returning to writing, I think, is because I feel like things that I'm thinking about are hard to put into tweets or smaller chunks of insight. So, yeah, probably my sub stack is the best place to find me, okay.
Marty Haught:Perfect Sarah. Thank you so much for joining us today.
Sarah Mei:Well, thank you for having me. This has been delightful.
David Hill:Thank you so much for tuning into the Ruby Gems podcast. We hope you enjoyed this episode. You can find show notes and links to everything we discussed at rubygemspodcastcom.
Marty Haught:If you have a topic you'd like us to cover or have feedback, we'd love to hear from you. Please email podcast at rubycentralorg. If you enjoyed this episode, please subscribe and consider leaving a five-star review. It really helps others find the podcast. Until next time, thanks for being such a gem.
