POPULARITY
4 episodes with railsbridge
5 episodes with railsbridge
4 episodes with railsbridge
2 episodes with railsbridge
2 episodes with railsbridge
6 episodes with railsbridge
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.
I have such a treat for you all today and it is completely unrelated to cooking, but it might just become your favorite Cook Smarts podcast episode. I’m excited to share another part of our origin story today -- there would be no Cook Smarts meal plan service without the talents and persistence of Jen Gilbert, who helped me build our meal plan service back in 2013. Jen and I met in the fall of 2012 at a Railsbridge workshop. We had both just turned 30 and made huge career changes. She wanted to learn to code to become a software developer, and I wanted to learn to code because I was determined to build a meal plan service. There were many challenges and hiccups along the way, but in the end we launched the service on May 1, 2013 with paying customers on day 1. Come join us in this walk down memory lane and hear how we made the impossible happen. Want to be a super supporter of the show and home cooking? Please tell a friend about our podcast and leave us a review on Apple Podcast (https://podcasts.apple.com/us/podcast/in-the-kitchen-with-cook-smarts/id1454754429?mt=2). Screenshot it and text it to 650-386-0290 for a chance to win a $100 Amazon gift card. If you’ve already left a review there, send us a voicemail review at the same number instead!
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.
This week, we talk to Fiona Voss. She is is a software engineer and a computer science student. We talk about how the theoretical can inform the practical, how one gets started in programming, and why she appreciates the Micro.blog community. “We feel we have something in common because we are on Micro.blog. We are on it because we care about community and we care about the open web.” Mentioned: RailsBridge
Hannah watched It at 10AM on a Saturday! Erin shares a less-than-inspiring story from the Winter Olympics. Ben's grad school adventures are continuing with a trip to VA! And that's just the upfront stuff! Hannah shares a new Netflix sci-fi obsession. Erin has been teaching classes in her spare time! Ben has been thinking a lot about a topic addressed in many works of Isaac Asimov. HOMEWORK: - Watch Altered Carbon on Netflix - Check out Railsbridge and Girl Develop It! if you're interested in getting into programming (but not sure where to start) - Read about the singularity - Read the Isaac Asimov short story The Last Question - Follow @ErnBrn, @NEDiscoGreg, @Hanthropology, and @TooBroadPod on Twitter - Follow LesbianMovieReviews on IG - Email us at waytoobroad@gmail.com - Join our Facebook group! - Please leave us a rating/review/subscribe on iTunes or wherever!
Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance. They also talk about transitioning from non-profits to coding. This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides
Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance. They also talk about transitioning from non-profits to coding. This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides
Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance. They also talk about transitioning from non-profits to coding. This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides
MRS 018: Kinsey Ann Durham Today's episode is a My Ruby Story with Kinsey Ann Durham. She is one of the speakers for the Ruby Dev Summit. Listen to learn more about Kinsey! [01:15] – Introduction to Kinsey Ann Durham Kinsey was on episode 180 of the Ruby Rogues podcast. They talked about Barriers to New Developers. It’s been 3 years. She is also one of the speakers for the Ruby Dev Summit, which is coming up in October. [02:55] – How did you get into programming? RailsBridge workshop Kinsey got into programming, not through the traditional Computer Science route or boot camp / code school route. She actually did a RailsBridge workshop 4 or 5 years ago in Denver. RailsBridge is part of the larger organization called Bridge Foundry. It’s a weekend workshop where you have mentors and teachers who teach you how to build an app in whatever language or framework from scratch. Food is provided. It’s mainly for women but men are welcome as well as long as you accompany a female. Brother Kinsey’s step brother, Sean Griffin, is really big in the Rails community and Rasp community. She saw him and what he was doing. Networking and building relationships Kinsey was lucky enough to meet Desi McAdam at the RailsBridge event. Eventually, she was able to get a job as an apprentice in Denver that had just opened and where Desi was the managing director. Kinsey did a lot of self-taught work using books. There are online tutorials, mentorship, and networking with people. She thinks it’s relevant for developers who are new in the industry given how saturated the market is. It’s important to network and build relationships, and not just applying blindly to Java applications that you see online. [06:20] – What do you recommend to people? Luckily, there are tons of online resources where you can learn and get the basics. Kinsey thinks that it’s a lot harder nowadays to do that because you will be competing for head to head with students who are coming out of these schools, or do have Computer Science backgrounds. But she also thinks that it’s doable to be self-taught as long as you are willing to put in the time. And then, not only use the free online resources but also find a mentor that is willing to work with you and guide you because there are times where you’ll hit a bug or problem or even when getting Rails setup on your machine. Sometimes, Stack Overflow and those online resources aren’t enough. [08:20] – How did Ruby shaped your experience coming in as a new programmer? Kinsey started going to conferences right away and she fell in love with the community. Back then, there were a lot of stories going around in the industry on how hard it is for females, etc. But she found that the Ruby community was welcoming and receptive. [10:00] – Sexism Kinsey had experiences and has seen it firsthand. She thinks that it is still an issue but she also thinks that it’s getting better. She thinks that the programming communities are becoming more and more diverse with the influx of people coming out of code schools. They have different backgrounds. They also have stereotypical developers. Picks Kinsey Ann Durham RubyConf Organization: Bridge Foundry Twitter: @KinseyAnnDurham Website: kinseyanndurham.com Charles Max Woods RubyRogues Parley RubyConf RailsConf
MRS 018: Kinsey Ann Durham Today's episode is a My Ruby Story with Kinsey Ann Durham. She is one of the speakers for the Ruby Dev Summit. Listen to learn more about Kinsey! [01:15] – Introduction to Kinsey Ann Durham Kinsey was on episode 180 of the Ruby Rogues podcast. They talked about Barriers to New Developers. It’s been 3 years. She is also one of the speakers for the Ruby Dev Summit, which is coming up in October. [02:55] – How did you get into programming? RailsBridge workshop Kinsey got into programming, not through the traditional Computer Science route or boot camp / code school route. She actually did a RailsBridge workshop 4 or 5 years ago in Denver. RailsBridge is part of the larger organization called Bridge Foundry. It’s a weekend workshop where you have mentors and teachers who teach you how to build an app in whatever language or framework from scratch. Food is provided. It’s mainly for women but men are welcome as well as long as you accompany a female. Brother Kinsey’s step brother, Sean Griffin, is really big in the Rails community and Rasp community. She saw him and what he was doing. Networking and building relationships Kinsey was lucky enough to meet Desi McAdam at the RailsBridge event. Eventually, she was able to get a job as an apprentice in Denver that had just opened and where Desi was the managing director. Kinsey did a lot of self-taught work using books. There are online tutorials, mentorship, and networking with people. She thinks it’s relevant for developers who are new in the industry given how saturated the market is. It’s important to network and build relationships, and not just applying blindly to Java applications that you see online. [06:20] – What do you recommend to people? Luckily, there are tons of online resources where you can learn and get the basics. Kinsey thinks that it’s a lot harder nowadays to do that because you will be competing for head to head with students who are coming out of these schools, or do have Computer Science backgrounds. But she also thinks that it’s doable to be self-taught as long as you are willing to put in the time. And then, not only use the free online resources but also find a mentor that is willing to work with you and guide you because there are times where you’ll hit a bug or problem or even when getting Rails setup on your machine. Sometimes, Stack Overflow and those online resources aren’t enough. [08:20] – How did Ruby shaped your experience coming in as a new programmer? Kinsey started going to conferences right away and she fell in love with the community. Back then, there were a lot of stories going around in the industry on how hard it is for females, etc. But she found that the Ruby community was welcoming and receptive. [10:00] – Sexism Kinsey had experiences and has seen it firsthand. She thinks that it is still an issue but she also thinks that it’s getting better. She thinks that the programming communities are becoming more and more diverse with the influx of people coming out of code schools. They have different backgrounds. They also have stereotypical developers. Picks Kinsey Ann Durham RubyConf Organization: Bridge Foundry Twitter: @KinseyAnnDurham Website: kinseyanndurham.com Charles Max Woods RubyRogues Parley RubyConf RailsConf
MRS 018: Kinsey Ann Durham Today's episode is a My Ruby Story with Kinsey Ann Durham. She is one of the speakers for the Ruby Dev Summit. Listen to learn more about Kinsey! [01:15] – Introduction to Kinsey Ann Durham Kinsey was on episode 180 of the Ruby Rogues podcast. They talked about Barriers to New Developers. It’s been 3 years. She is also one of the speakers for the Ruby Dev Summit, which is coming up in October. [02:55] – How did you get into programming? RailsBridge workshop Kinsey got into programming, not through the traditional Computer Science route or boot camp / code school route. She actually did a RailsBridge workshop 4 or 5 years ago in Denver. RailsBridge is part of the larger organization called Bridge Foundry. It’s a weekend workshop where you have mentors and teachers who teach you how to build an app in whatever language or framework from scratch. Food is provided. It’s mainly for women but men are welcome as well as long as you accompany a female. Brother Kinsey’s step brother, Sean Griffin, is really big in the Rails community and Rasp community. She saw him and what he was doing. Networking and building relationships Kinsey was lucky enough to meet Desi McAdam at the RailsBridge event. Eventually, she was able to get a job as an apprentice in Denver that had just opened and where Desi was the managing director. Kinsey did a lot of self-taught work using books. There are online tutorials, mentorship, and networking with people. She thinks it’s relevant for developers who are new in the industry given how saturated the market is. It’s important to network and build relationships, and not just applying blindly to Java applications that you see online. [06:20] – What do you recommend to people? Luckily, there are tons of online resources where you can learn and get the basics. Kinsey thinks that it’s a lot harder nowadays to do that because you will be competing for head to head with students who are coming out of these schools, or do have Computer Science backgrounds. But she also thinks that it’s doable to be self-taught as long as you are willing to put in the time. And then, not only use the free online resources but also find a mentor that is willing to work with you and guide you because there are times where you’ll hit a bug or problem or even when getting Rails setup on your machine. Sometimes, Stack Overflow and those online resources aren’t enough. [08:20] – How did Ruby shaped your experience coming in as a new programmer? Kinsey started going to conferences right away and she fell in love with the community. Back then, there were a lot of stories going around in the industry on how hard it is for females, etc. But she found that the Ruby community was welcoming and receptive. [10:00] – Sexism Kinsey had experiences and has seen it firsthand. She thinks that it is still an issue but she also thinks that it’s getting better. She thinks that the programming communities are becoming more and more diverse with the influx of people coming out of code schools. They have different backgrounds. They also have stereotypical developers. Picks Kinsey Ann Durham RubyConf Organization: Bridge Foundry Twitter: @KinseyAnnDurham Website: kinseyanndurham.com Charles Max Woods RubyRogues Parley RubyConf RailsConf
Chad is joined by Laurie Young to discuss The Developer's Path, a panel discussion hosted at thoughtbot London on how companies and developers can work together to achieve reciprocal growth. Developer's Path Panel Video thoughtbot Playbook- Apprenticeship Makers Academy Rails Girls London RailsBridge Over the Air Apprentice.io Laurie on Twitter
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.
Check out and get your ticket for Rails Remote Conf! 02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)
Check out and get your ticket for Rails Remote Conf! 02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)
Check out and get your ticket for Rails Remote Conf! 02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)
Check out RailsClips! 01:53 - Michele Titolo and Women Who Code Introduction Twitter Blog Facebook 02:15 - Origin Story 501(c) Organization 03:11 - Stated Mission “Inspire women to excel in technology careers” 04:12 - Mentorship Glassbreakers (A peer mentorship community for professional women) 08:54 - Getting Started and Getting Involved 11:27 - Value 12:42 - Remote/Virtual Membership/Communication 15:08 - What Makes Women Who Code Different (from other groups)? 18:02 - Is there a need for groups like this? What issues do these address? 22:34 - Implementing Diversity into the Workplace Job Postings Michele's tweet about a job posting Practical and Universal Interview Questions Workplace Culture Benefits Communication & Teamwork Cate Hudson: Programmers and Racecars 32:29 - Terminology (Using words like “guys”) 35:16 - Is it really harder for women to get jobs? Resume Anonymization Dropping Out/Reentering the Tech Industry Re-Recruit From the Leaky Pipeline (Model View Culture article) 43:13 - The Community at Large (How can we help make the community more open and welcome?) Inclusive Events Codes of Conduct Change Within *Your Own* Organization (Advocacy) Learning About Other People (Be Empathetic; Be Respectful) 46:08 - Are there people who can help people/companies diversify? Ashe Dryden The Diverse Team by Ashe Dryden The Ada Initiative Natural Introductions 49:49 - How can I help? (as a man) Donations Fund Club AlterConf Volunteering 51:47 - Study Resources (Proof) Model View Culture Cosmodrome (from Brianna Wu) Groups and Mailing Lists (mentioned in this episode) Glassbreakers Women Who Code SF (San Francisco) DevChix Tech LadyMafia Girls Who Code Black Girls Code PyLadies Ladies Who Code RailsBridge App Camp For Girls Girl Develop It Mobile Bridge Geekettes PowerToFly MotherCoders The Ada Initiative Fund Club AlterConf Picks Power Up Your Animations! with Marin Todorov (Alondo) Poker Theory & Analytics (Alondo) Paracord (Chuck) Soto Pocket Torch (Chuck) Kate Heddleston: How Our Engineering Environments are Killing Diversity (Michele) Ashe Dryden: The Responsibility of "Diversity" (Michele) Conference proposal writing: From brainstorm to submit @ 360iDev 2015 (Michele)
Check out RailsClips! 01:53 - Michele Titolo and Women Who Code Introduction Twitter Blog Facebook 02:15 - Origin Story 501(c) Organization 03:11 - Stated Mission “Inspire women to excel in technology careers” 04:12 - Mentorship Glassbreakers (A peer mentorship community for professional women) 08:54 - Getting Started and Getting Involved 11:27 - Value 12:42 - Remote/Virtual Membership/Communication 15:08 - What Makes Women Who Code Different (from other groups)? 18:02 - Is there a need for groups like this? What issues do these address? 22:34 - Implementing Diversity into the Workplace Job Postings Michele's tweet about a job posting Practical and Universal Interview Questions Workplace Culture Benefits Communication & Teamwork Cate Hudson: Programmers and Racecars 32:29 - Terminology (Using words like “guys”) 35:16 - Is it really harder for women to get jobs? Resume Anonymization Dropping Out/Reentering the Tech Industry Re-Recruit From the Leaky Pipeline (Model View Culture article) 43:13 - The Community at Large (How can we help make the community more open and welcome?) Inclusive Events Codes of Conduct Change Within *Your Own* Organization (Advocacy) Learning About Other People (Be Empathetic; Be Respectful) 46:08 - Are there people who can help people/companies diversify? Ashe Dryden The Diverse Team by Ashe Dryden The Ada Initiative Natural Introductions 49:49 - How can I help? (as a man) Donations Fund Club AlterConf Volunteering 51:47 - Study Resources (Proof) Model View Culture Cosmodrome (from Brianna Wu) Groups and Mailing Lists (mentioned in this episode) Glassbreakers Women Who Code SF (San Francisco) DevChix Tech LadyMafia Girls Who Code Black Girls Code PyLadies Ladies Who Code RailsBridge App Camp For Girls Girl Develop It Mobile Bridge Geekettes PowerToFly MotherCoders The Ada Initiative Fund Club AlterConf Picks Power Up Your Animations! with Marin Todorov (Alondo) Poker Theory & Analytics (Alondo) Paracord (Chuck) Soto Pocket Torch (Chuck) Kate Heddleston: How Our Engineering Environments are Killing Diversity (Michele) Ashe Dryden: The Responsibility of "Diversity" (Michele) Conference proposal writing: From brainstorm to submit @ 360iDev 2015 (Michele)
Sarah Allen, cofounder of RailsBridge and Bridge Foundry, joined the show to talk about the incredible ability to make something with software, leading and teaching a community, teaching programming to kids, programming is a life skill, and more.
Sarah Allen, cofounder of RailsBridge and Bridge Foundry, joined the show to talk about the incredible ability to make something with software, leading and teaching a community, teaching programming to kids, programming is a life skill, and more.
02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)
02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)
02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)
02:32 - Mark Bates Introduction Twitter GitHub Blog Boston Ruby Users Group @bostonrb MetaCasts: HD Screencasts for GO Enthusiasts @metacasts 03:14 - Scott Feinberg Introduction Twitter GitHub Blog WePay @WePay @wepaystatus 03:46 - Community Values 2014 Videos - WindyCityRails Lightning Talks (Scott’s is first) Scott Feinberg: Where does Ruby go from here? (The Happiness Manifesto) [GitHub] the-happiness-manifesto 05:32 - Ruby Community Standards and Values Testing Programming Should Be Fun and Enjoyable Pairing Large Regional Conferences and Meetups 07:33 - User Groups Lambda Lounge @LambdaLounge Netflix Open Source Group 10:18 - Polyglot Conferences Midwest.io 2014 - MythBashers: Adventures in Overlooked Technologies - Avdi Grimm [GitHub] A web server written in Bash Great Wide Open @AllThingsOpen CodeMash @codemash 13:07 - Including and Getting Newbies Involved in Conference and Community Culture Generations Boot Camps Launch Academy @LaunchAcademy_ Hugs 20:41 - Diversity and Codes of Conduct PyLadies PyLadies Chapters (Twitter) RailsBridge @railsbridge Rails Girls @railsgirls 23:08 - AlterConf @AlterConf Ashe Dryden @ashedryden 24:22 - PyCon @pycon 25:31 - HappinessConf @Happiness_Conf Diversity Black Girls Code @blackgirlscode Women Who Code @WomenWhoCode 28:30 - Developer Happiness and Invoking Community Values Within Corporate Company Culture Ruby Rogues Episode #191: The Developer Happiness Team with Kerri Miller PluralSight PluralSight Author Summit Trust Roles of Influence Navigating Office Politics 38:03 - Agile Software Development and Productivity The 4 Disciplines of Execution: Achieving Your Wildly Important Goals [TED Talk] Bruce Feiler: Agile programming — for your family 40:41 - “The Ruby Diaspora” Mark Bates - Panel: The Future of Ruby - Burlington Ruby Conference 2014 Elixir Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas The Go Programming Language Gophercon @GopherCon 47:47 - Acceptance Accepting Acceptance / Tolerating Intolerance 50:55 - Mentoring Boston Ruby’s “Project Night” Mentor Someone Who Doesn’t Look Like You Picks Love Letter (Coraline) RescueTime (Coraline) Hacking Happy by Dusty Phillips (Jessica) Happiness Conf Coupon Code (Scott) HappinessConf Speakers Page (Scott) The Flight Deal (Scott) iStat Menus (Scott) HappinessConf (Mark) The Go Programming Language (Mark) Use the Coupon Code: ROGUES to get your first month free: MetaCasts.tv: HD Screencasts for GO Enthusiasts (Mark)
02:32 - Mark Bates Introduction Twitter GitHub Blog Boston Ruby Users Group @bostonrb MetaCasts: HD Screencasts for GO Enthusiasts @metacasts 03:14 - Scott Feinberg Introduction Twitter GitHub Blog WePay @WePay @wepaystatus 03:46 - Community Values 2014 Videos - WindyCityRails Lightning Talks (Scott’s is first) Scott Feinberg: Where does Ruby go from here? (The Happiness Manifesto) [GitHub] the-happiness-manifesto 05:32 - Ruby Community Standards and Values Testing Programming Should Be Fun and Enjoyable Pairing Large Regional Conferences and Meetups 07:33 - User Groups Lambda Lounge @LambdaLounge Netflix Open Source Group 10:18 - Polyglot Conferences Midwest.io 2014 - MythBashers: Adventures in Overlooked Technologies - Avdi Grimm [GitHub] A web server written in Bash Great Wide Open @AllThingsOpen CodeMash @codemash 13:07 - Including and Getting Newbies Involved in Conference and Community Culture Generations Boot Camps Launch Academy @LaunchAcademy_ Hugs 20:41 - Diversity and Codes of Conduct PyLadies PyLadies Chapters (Twitter) RailsBridge @railsbridge Rails Girls @railsgirls 23:08 - AlterConf @AlterConf Ashe Dryden @ashedryden 24:22 - PyCon @pycon 25:31 - HappinessConf @Happiness_Conf Diversity Black Girls Code @blackgirlscode Women Who Code @WomenWhoCode 28:30 - Developer Happiness and Invoking Community Values Within Corporate Company Culture Ruby Rogues Episode #191: The Developer Happiness Team with Kerri Miller PluralSight PluralSight Author Summit Trust Roles of Influence Navigating Office Politics 38:03 - Agile Software Development and Productivity The 4 Disciplines of Execution: Achieving Your Wildly Important Goals [TED Talk] Bruce Feiler: Agile programming — for your family 40:41 - “The Ruby Diaspora” Mark Bates - Panel: The Future of Ruby - Burlington Ruby Conference 2014 Elixir Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas The Go Programming Language Gophercon @GopherCon 47:47 - Acceptance Accepting Acceptance / Tolerating Intolerance 50:55 - Mentoring Boston Ruby’s “Project Night” Mentor Someone Who Doesn’t Look Like You Picks Love Letter (Coraline) RescueTime (Coraline) Hacking Happy by Dusty Phillips (Jessica) Happiness Conf Coupon Code (Scott) HappinessConf Speakers Page (Scott) The Flight Deal (Scott) iStat Menus (Scott) HappinessConf (Mark) The Go Programming Language (Mark) Use the Coupon Code: ROGUES to get your first month free: MetaCasts.tv: HD Screencasts for GO Enthusiasts (Mark)
02:32 - Mark Bates Introduction Twitter GitHub Blog Boston Ruby Users Group @bostonrb MetaCasts: HD Screencasts for GO Enthusiasts @metacasts 03:14 - Scott Feinberg Introduction Twitter GitHub Blog WePay @WePay @wepaystatus 03:46 - Community Values 2014 Videos - WindyCityRails Lightning Talks (Scott’s is first) Scott Feinberg: Where does Ruby go from here? (The Happiness Manifesto) [GitHub] the-happiness-manifesto 05:32 - Ruby Community Standards and Values Testing Programming Should Be Fun and Enjoyable Pairing Large Regional Conferences and Meetups 07:33 - User Groups Lambda Lounge @LambdaLounge Netflix Open Source Group 10:18 - Polyglot Conferences Midwest.io 2014 - MythBashers: Adventures in Overlooked Technologies - Avdi Grimm [GitHub] A web server written in Bash Great Wide Open @AllThingsOpen CodeMash @codemash 13:07 - Including and Getting Newbies Involved in Conference and Community Culture Generations Boot Camps Launch Academy @LaunchAcademy_ Hugs 20:41 - Diversity and Codes of Conduct PyLadies PyLadies Chapters (Twitter) RailsBridge @railsbridge Rails Girls @railsgirls 23:08 - AlterConf @AlterConf Ashe Dryden @ashedryden 24:22 - PyCon @pycon 25:31 - HappinessConf @Happiness_Conf Diversity Black Girls Code @blackgirlscode Women Who Code @WomenWhoCode 28:30 - Developer Happiness and Invoking Community Values Within Corporate Company Culture Ruby Rogues Episode #191: The Developer Happiness Team with Kerri Miller PluralSight PluralSight Author Summit Trust Roles of Influence Navigating Office Politics 38:03 - Agile Software Development and Productivity The 4 Disciplines of Execution: Achieving Your Wildly Important Goals [TED Talk] Bruce Feiler: Agile programming — for your family 40:41 - “The Ruby Diaspora” Mark Bates - Panel: The Future of Ruby - Burlington Ruby Conference 2014 Elixir Programming Elixir: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas The Go Programming Language Gophercon @GopherCon 47:47 - Acceptance Accepting Acceptance / Tolerating Intolerance 50:55 - Mentoring Boston Ruby’s “Project Night” Mentor Someone Who Doesn’t Look Like You Picks Love Letter (Coraline) RescueTime (Coraline) Hacking Happy by Dusty Phillips (Jessica) Happiness Conf Coupon Code (Scott) HappinessConf Speakers Page (Scott) The Flight Deal (Scott) iStat Menus (Scott) HappinessConf (Mark) The Go Programming Language (Mark) Use the Coupon Code: ROGUES to get your first month free: MetaCasts.tv: HD Screencasts for GO Enthusiasts (Mark)
Adarsh talks Jessie Young, who started her professional life as a political volunteer, worked in marketing, and became a developer after attending a technical bootcamp. PDA Edward "Ted" Kennedy Brookline, MA Sermo RailsBridge "Head First HTML with CSS" by Elisabeth Robson, Eric Freeman (not Kathy Sierra as I had thought) "Learn to Program" by Chris Pine Hungry Academy Dev Bootcamp Pivotal Labs
Sara Mei joins us this week to discuss passion and whether it's a job requirement that you "love programming". She's a Chief Consultant at DevMynd, a co-founder of RailsBridge, and an all-around rad human. Today we talk about whether it's okay to get your motivation from things other than your sheer passion for programming, such as societal impact or what you can do with your code. The tweet that started it all Sarah Mei RailsBridge Sara at DevMynd Sarah's new book with Sandi Metz The Moderately Enthusiastic Programmer The Passion Gospel
In this episode, recorded at RailsConf 2013, Ben Orenstein is joined by Gregg Pollack and Nathaniel Bibler from EnvyLabs and codeschool.com. Gregg shares what he's learned running his business, when not to be transparent, how to deal with compensation, and how the EnvyLabs compensation structure has changed over the years. Nathan, Gregg, and Ben also discuss Code School, yearly payments to a subscription, making courses effective, effective marketing, the effectiveness of mailing lists, community events, shared ownership, and much more. Code School RailsBridge Barcamp Orlando Ruby5 podcast Follow @thoughtbot, @r00k, @greggpollack and @nbibler on twitter.
Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology. RailsBridge Pivotal Labs Follow @thoughtbot, @sarahmei, and @r00k on twitter.
Audio File: Download MP3Transcript: An Interview with Sarah Allen CTO, Mightyverse Date: January 14, 2011 Interview with Sarah Allen [intro music] Lucy Sanders: Hi, this is Lucy Sanders. I'm the CEO of NCWIT, the National Center for Women in Information Technology. This is the next in a series of just great interviews with entrepreneurs who have started some really interesting companies and our interviewee today is no exception. With me is Larry Nelson from W3W3. Hi Larry. Larry Nelson: Hi, I'm happy to be here. This is an exciting series. Lucy: What's going on with W3W3? Larry: Well, we're interviewing all kinds of interesting people. Now, we don't interview only women, just so you know. Lucy: Oh, OK. Larry: Our interview not too long ago with Leonard Nimoy was fantastic. Lee Kennedy: You're such a bragger. [laughs] Larry: Yes. I couldn't help it. Lucy: Also with me is Lee Kennedy, who is a director of NCWIT and also a serial entrepreneur. Her latest company is Boulder Search. Welcome Lee. Lee: Thanks Lucy, always great to be here. Lucy: Today we're interesting a really busy, interesting person, Sarah Allen. She's currently the CTO and co-founder of Mightyverse. I went and played around at Mightyverse and you just must go. All the listeners must go to Mightyverse and play with it. I don't know, Sarah, if that's the right thing to say, play with it, or not, but I had great fun looking for languages and thinking about phrases. Basically what you've created at Mightyverse what you're calling a language marketplace. And you just don't see a pronunciation or hear a pronunciation, but you see people's faces actually saying it. It looks good on your mobile device. You can be anywhere and go figure out how the heck to say something. Sarah is primarily self-funding this company through some independent consulting work. And one other thing before we get to the interview, I wanted to say especially to our listeners who follow NCWIT and what we do, Sarah has started RailsBridge which is providing free workshops teaching Ruby on Rails aimed at women. Thank you for doing that Sarah and welcome. Sarah Allen: I'm very happy to be here. Lucy: Before we start, why don't you tell us a little bit about Mightyverse, over and above what I said, as a way of introduction? Sarah: Well, I think that it's fine to say that you played with it. I feel like playing is the best way to learn. We definitely want to create an engaging way to learn how to speak languages. And I'm really excited that we just released a collection of Hebrew phrases on the iPhone. So if you have an iPhone or an iPad you can go to the store and for 99 cents get a collection of Hebrew phrases. And we're really in a phase where we're market testing the mobile angle of Mightyverse. So you can see the full collection on the web but we're releasing a series of collections to get feedback from people about the mobile experience. Lucy: Well, people in the Bay area, I think you can show up and record your phrases and maybe even get a free lunch from Sarah? [laughter] Sarah: Absolutely. If anybody wants to come and record a phrase in their native language we'd be delighted to have you as our guest. Lucy: Sarah, you are quite a technologist, obviously you're a chief technology officer. But prior to your work at Mightyverse, you've worked in Shockwave and Flash and you were named one of the top 25 women on the web in 1998. So a very amazing technology career. How did you first get into technology? Sarah: Well, I started programming in Basic on an Apple II, back in the day when your computer would arrive with a manual that taught you Basic. I really taught myself from a book that shipped with the Apple at that day. And I got into it because my mom went into selling computers after being laid off from teaching in the public schools in the Boston area. And so, she brought an Apple II home and I taught myself. Larry: Wow. Lucy: Basic, I learned Basic in my high school math class. Lee: That's amazing. Had you done other kind of techie things before you jumped into that? Sarah: I think that that was the first really technical thing that I had done. I didn't see a big division between technical things and non- technical things. My dad had a philosophy where he would always teach both my brother and me everything that he did. He did handy stuff around the house and fixed cars. He taught us both math and different things. So I didn't really see that the computer was a really technical thing. I thought that building physical circuits was really technical and I thought that fixing cars was really technical. But I thought that it was just a toy. Lee: Yeah. Sarah: I knew it was a serious thing for my mom and for other people. I approached it as like this adventure, like "Oh, let's play with this thing." Lucy: Certainly from your position as a CTO, you're always assessing technologies and listeners are always curious to know which ones you see as being the most exciting. Sarah: Well, I think right now mobile is super exciting. But what's most exciting about mobile is the fact that we now have these huge data storage that we can access. We have cloud computing so that it's really easy to deploy services and to access data stores. We're starting to see a lot of easily interconnected web services. I think we're finally approaching what Tim Berners-Lee meant by the semantic web, this notion of having these services on the web that you can connect to and machines can connect to and make sense of. So, we're starting to be able to assemble fairly complex systems without building every piece ourselves. I think that's really exciting. Lucy: So it's clear how you got into technology. How did you get into being an entrepreneur? Sarah: Well I feel like I kind of stumbled into entrepreneurship because all through college I was a teaching assistant at this one class. And these two guys who TA'd with me and then we were head TAs. And we did a number of projects together, coding together. And they both hooked up with another friend of theirs and they decided to start a company. So this happened about six months before I graduated because I graduated in the middle of the year. So I did as like "Well, my friends are starting this company. I'll work there for the summer." And kind of fell into it because I got wrapped up in what we were doing and ended up really being a co-founder of that company. And that was CoSA, which was a company that created After Effects, which is now sold by Adobe. That really gave me the feel for what it meant to be involved in a startup company which otherwise I don't think I really would have understood how exciting that is and why I would have wanted to do it. Lucy: Tell us what it is about being an entrepreneur that you love so much. Sarah: Well, I really love creating things that don't exist and solving problems that either people don't see or they don't realize can be solved by today's technology. I think that's really exciting. The thing that convinced me to actually be a software developer, because I graduated from college... I graduated with a CS degree. But I didn't think I was going to be a software developer because I thought it was straightforward. I thought it was like doing crossword puzzles or Rubik's cubes. It's entertaining. But I didn't really take it seriously. I didn't see when I was in college the power of computing and how it can be applied to real world problems because everything seemed really obvious to me. So I figured anybody could do it. And then when I was working at CoSA, CoSA actually was a very small company. We also kept up tech support. And I remember somebody who was calling to ask me about a question who had bought our software said "I didn't think computers could do this." And I realized that I had a unique perspective that I never recognized before. Because of my experience, because of my skills, because of my unique world view, I can see things that I'm not the only person who sees. But the majority of the world doesn't and that's a real opportunity for me. That's kind of exciting. Larry: Boy, I'll say. Well you mentioned your parents. It was really neat how they had a way of helping steer you somewhat. But I want to talk about your career. Who are some of the people along the way that have supported your career, whether they be mentors or role models or whatever? Sarah: Early in my career I really struggled with not seeing women role models. That was really important to me. I felt a little isolated. I was often the only woman on my team. I did find men who were great role models. Harry Chesley, who created the Shockwave team and hired me at Macromedia, was the person I learned about the Internet from. He was the first person who I ever heard say that he wanted to work on open source. I asked him what he would want to do if he made it rich and could retire early and he said he would want to write software for free. And I thought that was really bizarre and now I understand what that means. Lucy: Yeah. Sarah: And my friend David Simons who I started CoSA with who still works on After Effects at Adobe. He's really always inspired me because he stays true to himself. He always respected me. And he always saw, I think even before I saw things in myself he saw them in me, in terms of what I could do. Our collaboration showed me how we could work together. And those kinds of relationships were really inspiring. It may sound clich�, but my husband has been incredibly supportive, I think another person who will see in me things before I recognize them myself. Having his support in picking through these career choices is super, super important. But after a while I started to get frustrated that I didn't have women ahead of me. I started to feel that maybe I didn't belong. Maybe this wasn't the career for me. Were some of the things happening that I didn't like because of my gender? I didn't know and I felt uncertain about that. I actually read this book about the 50 Nobel prize winners in math and science who are women. And I read an essay about Emmy Noether, who is a German mathematician who was actually the first woman to be paid to be a professor in Germany. But before that she did math because she loved doing math and she lectured under somebody else's name because she was so thrilled with the opportunity to talk to people about her ideas about math. She helped Einstein lay the mathematical foundation for his theories of relativity. Lucy: Wow. Sarah: She was just very excited to work with people who had respect for her so it didn't matter that she didn't get paid for it, that the rest of the world didn't acknowledge it because in her small circle, they all knew that Emmy was the person to go to when you had a math question. Then I looked around me and I saw that, OK, I have this group of guys who all respect me and we build great software. I was working on Flash video at the time, working with an amazing team. And I just felt like "Well, this is what I love to do. Forget all of that nonsense. I'm just going to follow what I love and the rest will take care of itself." Lucy: Well, that's a great story. I think, too, some of the work you're doing with Ruby on Rails giving women the confidence and skill set to get out there and to start contributing in a space is really going to also add role models. Sarah: It is my hope. Lucy: And thank you for doing that. So, we are going to turn now, away from technology and mentoring into sort of the dark side of the career. [laughs] And asking about the toughest thing you ever had to do so far in your career. Sarah: This is actually the hardest question. I am thinking about this interview. There isn't one thing. The hardest thing is really making decisions like the hardest thing for me, it may sound a little tried, is just making priorities, making decisions. I used to feel that they were right answers, and that if there were some negative consequence to a decision I made that then I have made the wrong answer. And what I come to realize is that every decision comes with risks and if am deciding am I going to do A or B or C, each thing has potentially negative consequences. And to make a decision with your eyes open and to say "OK I am going to do this and there might be some fallout and I might do it anyhow." I feel like I make those decisions 20 times a day running a company. I make new significant technical decisions for my neighbors who make strategic decisions, who make those life decisions. Should I be spending this much time on my career instead of my family? It's not really that kind of either/or but all the little decisions add up and they have consequences both good and bad. So, I think that's the hardest thing. Lucy : Well and sometimes, too, I think. You think if you don't do anything. There is no risk with doing nothing and not making decision, whereas in fact, right? Larry: Yeah. Sarah: That's the biggest risk. Lucy: That's the biggest risk of all. Sarah: I mean I think that, I probably instead of the most wide spread computer software that I've ever developed was Shockwaves where I wrote... Even though there were only four engineers in the project. I wrote a significant amount of code. I was involved with many, many releases of it. I don't think I got any real risk in developing that. I never did anything that I wasn't sure what's going to work. I really like the civilization in the late 90s. I have never really taken real risks in my career, and so later I started to try to take risks. I was able to do much more impressive things because they didn't know it worked the first time. But if you make a decision, you try to do something knowing that it might not work and litigate that. You can lay a path. You can set expectations that you are experimenting and then you are able to do things that are much more clear. Lucy: And that brings us to the next question when you think back about all the things you have done in your career, whether it's working with technologies, making decisions or what to do. If you are kind of sum it all that and give advice to somebody that's looking to get in to being an entrepreneur, what advice would you give them? Sarah: I have couple of pieces of advices. The number one piece of advice is to pick the people you work with first, it's more important than the project, the technology anything else. It's that you are working with great people that you respect for, that you can learn from, that they have respect for you and that you are going to have a great working environment. When I went to college, I would say pick your college class by the professor not by the subject. I feel that's completely true for your working environment. So if you think it's an amazing job but you are not sure about the people or an "OK" job with amazing people, take the OK job with amazing people because the amazing people will turn it into an amazing job. It's more likely your project is going to change than the people change. So, that's the first thing which I think is really important Lucy: And that's great advice. Larry: Yeah, you got it. Lucy: Very true. Sarah: The second thing is to really find your passion. Find the things that makes you tick, find the things that you love. What is the thing that you can do just forever and never get bored of? And that's what you should be doing. It can be very, as a young person, I didn't know what that was. But when I found it and I didn't recognize that when I found it that I kept following it. What's this thing that I am into? I would pick things. It felt like I was making career choices on a lark. But I would just follow my gut instinct about this. This feel is exciting to me and then in retrospect, I could see a pattern, but it was seven or eight years before I saw a pattern. But I was following what is it that drives me? What is that excites me and that lead me to where I am today. Larry: Very good, great advice. What are your personal characteristics that have given you the advantage of being the entrepreneur? Sarah: It's kind of a hard question because I feel like I'm such a different person than I was when I started being an entrepreneur and I feel that the things that made me successful now, they feel like there are very different things that made me successful then. But I think the common thread that runs through it is that it's creative work. At least this is my angle at it. In college, I got two degrees. One in computer science and the other in visual arts. I am at studio art. There are two things that I learned. One was in being creative, sometimes that blank canvass if you want enemy. You need edit the paper. You need to pour your creativity into and creativity is work, like creating that structure for yourself. Creating the path, getting yourself into the creative mindset is working at a discipline. The other thing is being able to receive and give in an affective critique. One of the things that you learned in Art 101 or whatever they called it is we did lots of drawings. Everybody would put their art in the wall and you were supposed to critique it. I would come and I would look at a drawing. It would be like Oh, my God. I can't believe that person just turn that in. [laughter] Sarah: And if you would say, the composition of the little jumbo but this quality of line really speaks to me. I like the gracefulness of that line and I learned to pick out the parts of a drawing that were really wonderful and disregard the thing that didn't turn out OK. And that made me not only be able to communicate more effectively but more importantly, see things that I otherwise wouldn't see. I think those skills lead me to be able to interact with people and hone my own skills in a way that to give me an advantage of an entrepreneur. Lucy: I think that's great. Was that your picture that she said about Larry? Larry: Maybe. Lucy: Maybe just a little? Sarah: I would never say. Lucy: No, never say. Larry: Thank you. Thank you. Lucy: No, never say but I just thought that was wonderful. Just to say it. Now, Sarah, you mentioned in your earlier question around decision making about is it the right time for me to be spending this time away from my family and working so much in my career? And so, get us to our next question about bringing balance to your personal and professional lives. Any advice you would like to give the listeners about that? Sarah: First off, I'm probably the worst person to give advice about work right now. Lucy: Go ahead. Yeah? Sarah: I do have a family. I love my family. I wish I could spend more time with them which is ironic because it obviously not a big enough wish to overcome my drive to do other things in my life. And so, in that way you have to have some kind of balance. You have to figure out how you are going to make peace with all of these things that you want in your life. I was very influenced by a woman. I don't know her name who gave a talk at Grace Hopper Celebration of Women Computing. I think it is 1997. Right around that time, I was either pregnant or about to be and it was that talk about having children and having a technical career in. For the first time I heard somebody who actually said that she thought that having a career in technology was an advantage for being a mother. I was expecting to hear all about compromise. But she said it was an advantage and she went through a lot of ways that it really helped her relation with her son. And, what she said was, "You can have it all, just not all at once." Lucy: That's a good way to put it. Sarah: That's what I try to do at my best. That when I am home with my family, I am there with them. Like I'm most successful when I can make time to do what I am doing and really do it fully and then decide that "OK, this is time I am not going to spend with my family. I'm going to spend it on other thing and really spend it at that. If you can do that successfully then I think you can have really great balance. But it is really challenging. But it is incredibly rewarding when it does work. Lucy: Sarah, we've really enjoyed talking to you. Just feels like you've got this Zen about you. So, tell us what's next for you? Sarah: Well, a lot of things. I am really excited about RailsBridge becoming self sustaining. I read a great book "The Starfish and The Spider." Its subtitle is the "Unstoppable Power of Leaderless Organizations" I'm taking a bunch of lesson on that book in trying to create, help create or empower this group of volunteers and create structure around it so that it can just... The workshops can be self sustaining and don't need me as a leader. Or don't need any leader and they can just work by themselves. It's really exciting that's starting to happen. Also, I'm working to have my consulting company with this grown up around me. It started with just a way to fund my product development ideas but that also started to become a self sustaining company. And then, that will really liberate me to focus on my neighbors. I am really excited to spend more time writing code, spend time figuring out the hard problems around language or even better yet, figuring out the easy problems that are going to be most rewarding first. It's such a vast problem space but there are also so many things that don't require a lot of technology. I am excited about a problem which is as much a human problem as it is a problem for technology. Larry: Excellent. Lucy: Well, we are going to stay tuned, that's for sure. Larry: Yeah. Lucy: Well, thanks very much Sarah. It was great talking to you. I want to remind listeners where they can find these interviews at w3w3w3.com and ncwit.org. Larry: We are really looking forward to it. We are going to follow you, Sarah. Sarah: Great, you can follow me on Twitter at my hacker identity. It's all sorts.com. Like the dinosaur. Lee: OK. Cool. We will be there. Lucy: Thank you so much. Sarah: All right. Series: Entrepreneurial HeroesInterviewee: Sarah AllenInterview Summary: Sarah Allen is a serial innovator with a history of developing leading-edge products, such as After Effects, Shockwave, Flash video, and OpenLaszlo. She has a habit of recognizing great and timely ideas, finding talented teams, and creating compelling software. Release Date: January 14, 2011Interview Subject: Sarah AllenInterviewer(s): Lucy Sanders, Larry Nelson, Lee KennedyDuration: 23:55
Kinsey Durham Grace is an Enterprise Infrastructure Engineer at GitHub. She is also a lecturer at RailsBridge where they run a workshop to teach scholars to write code. She joins the show with John and Valentino to about a variety of topics mostly focused on DevOps and Mentoring. She shares her experience in teaching scholars in the Ruby Community. Additionally, she talks about her career transition from Go to Ruby. SponsorsAppSignalDeveloper Book Club starting with Clean Architecture by Robert C. MartinBecome a Top 1% Dev with a Top End Devs MembershipLinksKinsey Durham GraceGitHub: kinseydurhamgraceTwitter: @KinseyAnnDurhamPicksJohn - Rented office spacesKinsey - Ruby CentralKinsey - BridgeFoundry Valentino - Mexico City Rails Meet-up RebootAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
Kinsey Durham Grace is an Enterprise Infrastructure Engineer at GitHub. She is also a lecturer at RailsBridge where they run a workshop to teach scholars to write code. She joins the show with John and Valentino to about a variety of topics mostly focused on DevOps and Mentoring. She shares her experience in teaching scholars in the Ruby Community. Additionally, she talks about her career transition from Go to Ruby. SponsorsAppSignalDeveloper Book Club starting with Clean Architecture by Robert C. MartinBecome a Top 1% Dev with a Top End Devs MembershipLinksKinsey Durham GraceGitHub: kinseydurhamgraceTwitter: @KinseyAnnDurhamPicksJohn - Rented office spacesKinsey - Ruby CentralKinsey - BridgeFoundry Valentino - Mexico City Rails Meet-up RebootAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
© 2020-2025 Ivy Podcast Discovery LLC
