CORALINE: Hello and welcome to the special RailsConf edition of Greater Than Code sponsored by O’Reilly and Cloud City. We’re very thankful to our sponsors for making this possible. And today is also very special because we have a live audience, or at least 150 people here. [Cheers] CORALINE: I’ve memorized all of their names, which I’m quite impressed with myself over. Today is also really exciting because we have a brand new panelist who’s joining the show. Would you like to introduce yourself? JOHN: Sure. I’m John Sawers. And I’m so excited to be part of this wonderful group of people. CORALINE: Awesome. We’re happy to have you. We also have some guest panelists with us today. VAIDEHI: Hello, everyone. My name is Vaidehi Joshi. Should I saw some words about myself? CORALINE: Sure. VAIDEHI: That seems good, right? CORALINE: Yeah. VAIDEHI: That’s usually what you do after you say your name. I am an engineer at Tilde in Portland, Oregon where I work on Skylight, your favorite Rails profiler. And I’m also really into computer science. I have a side project called BaseCS. It’s a written series. And I’m also the cohost of my own podcast called the Base.cs Podcast. CORALINE: Awesome. DINAH: And my name is Dinah. I am a student at the University of Waterloo where I study software engineering. But I’m 99.9% of the way through my undergraduate degree, which is to say that I’m waiting for my diploma. I also have… CORALINE: So am I. [Laughter] 20 years. DINAH: Oh gosh. I hope that doesn’t happen to me. CORALINE: I’m holding out for an honorary degree at this point. DINAH: It’ll happen. I believe it. CORALINE: Yeah. DINAH: I also help organize Women Who Code Waterloo which is a local chapter in the city that I go to school. And I am a Rails contributor. CORALINE: Yay, awesome. JOHN: Cool. NICK: My name’s Nick Quaranto. I’m known as @qrush on Twitter, or some people say “crush”, I’ve learned, which both are acceptable. I work for a company called Chatterbug. We’re a language learning app. But I’m mostly known for starting what is now called RubyGems.org. It used to be called Gemcutter. And I’ve been involved with Ruby and open source for a number of years. I’m just getting back into it. And I’m so excited to see everyone. So excited about open source in general and really happy and passionate at this conference after being involved for almost a decade now. It’s so amazing to see everyone happy and pumped. So, I’m really happy to be here. CORALINE: Awesome. I feel like we’re missing somebody. JAMEY: Nope. That was it. CORALINE: I’m pretty sure we’re missing somebody. JAMEY: I’m also here. Jamey Hampton from Greater Than Code. [Chuckles] JOHN: Hi, Jamey. CORALINE: Hi, Jamey. JAMEY: Hi, everyone. [Laughter] I’m going to say hi individually to all 150 people who are here. That’s the show. [Laughter] CORALINE: We’re going to go around the room and ask everyone for their superpower. You have 20 minutes. So, we thought we’d do something a little different today because we don’t have a guest and we thought about like, “Oh, we could take questions from the audience,” or we could do this or that. And what we settled on is we want to talk about – and this hits to the core premise of the show – we want to talk about our relationship to our code. And if you know me at all, you know I’m going to rant about the meritocracy a little bit, so stay tuned for that. But as developers, the primary way that we’re measured, that our worth is measured unfortunately in our late capitalist society, is our output, the code that we write. And a lot of us have emotional connections to our code which is understandable, because writing code can be a very personal and emotional experience. But one of the trends that I’ve seen is people defining themselves by the code that they write. And that strikes me as really, really unhealthy. Maybe fellow panelists disagree with this. I’d love to have a discussion around it. So, maybe we could start out by saying: what is your relationship to the code that you write? How do you feel about it? VAIDEHI: Everyone’s looking at me. I guess I have to go first. [Laughs] NICK: I’ll [inaudible] this. JAMEY: I was looking at Nick because he made like a noise. VAIDEHI: Oh, okay. NICK: I make noises. So, I apologize to the future editors of this. MANDY: It’s okay. NICK: I’m over – thank you to Mandy for editing my noises. I feel like I’m always overly emotional about everything that I’ve created, because simply it’s a work of creation. It’s something that you put your heart into. And if you care about this craft and if you care about how others will read the thing that you wrote, which we all know is read more than it’s wrote, then it’s like you just pour so much of yourself out. And it’s very hard for me personally to be like, “Okay. No, this is like, actually you need to treat it as this objective thing.” But fundamentally it’s a subjective thing that you’re writing. CORALINE: Yeah. NICK: So, I have a lot of trouble with that separation of the objective and subjective. Especially when it’s a thing that you actually write, like words. [Chuckles] JAMEY: I agree. I feel like I get attached to my – especially when I was newer in the industry and newer at writing code. I got very attached to the code that I wrote and I felt, I had a really hard time deleting any lines of code that I wrote. I got very emotional about like, “No, I worked on this. We have to keep it,” which is unhealthy. I actually got in trouble one time when I was still in college because I was working on a project and I had written a block of code and tested it and it worked, but it was kind of like messy. And I was like, “I think I might be able to do this better, but I’m going to keep it because I just need to keep it. And maybe my new one won’t work and I’ll want to go back to it.” So, I commented out the first block and then I wrote a better block and I left it. And I never took it out and I turned it in. And I got pinged for, my professor thought I was plagiarizing. Because he’s like, “You have this commented out code that doesn’t do anything. You obviously copied and pasted this.” And I was like, no. I’m just very neurotic. [Laughter] And when I first started in the industry, I felt the same way about deleting code. And in the past maybe six months or a year or so, I’ve found that I have started to really like tearing out code. I’ve started to realize that it feels really good to be like, “We don’t need any of this anymore. Goodbye, goodbye, goodbye.” And so, I feel like that’s my character development. It’s happening. [Chuckles] VAIDEHI: Yeah, I think one of the things I really have gotten around to, it took a while, is the versions that I’m attached to that end up changing are the ones that I will go back to later after I’ve either had code review or iterations on it. And then I’m like, “I know I was emotionally attached to this then. But now that I’m looking at it, I’m like, oh, this actually is a great diary of what I learned in the process of working on this feature or learning this new language or trying to implement this thing.” And that actually makes me less invested and emotionally connected to the code but more the learning process that went into it. Because down the road, if you end up abandoning that language or you work at a different company where you’re never going to use that framework, honestly, like whatever. You’re not going to use the same lines of code. But the things you learn in that process, like a concept, like functional programming techniques or how to refactor things or how to extract things, learning those things, getting emotionally attached to the process of learning those things, are the things that I feel are maybe more healthy than the lines of code and implementation details themselves. CORALINE: Yeah. I invented a joke that about 500 other programmers also invented. [Laughter] I thought I was being clever, and no. This was at a talk several years ago about refactoring. And I talked about doing ‘git blame’ on the code and finding that it was your own code. And the joke is that you feel bad and you’re like, “Oh my god. I was such an idiot.” But to your point, it demonstrates that you’re learning and growing. And it is a snapshot of a moment in time. It’s not your identity but it’s a reflection of who you are at a certain point in time. VAIDEHI: Yeah. CORALINE: And so, it is a record, kind of, of where you’ve been. And going back to old code can be great because you’re like, “Wow. I didn’t know about X back when I wrote this.” And you think about how you would do it differently now. And it’s like a reminder that you’re progressing, that you’re getting better at your craft, and you’re always learning and growing. VAIDEHI: Yeah. It’s actually, I feel like what you just said makes me think it’s kind of empowering to embrace what you didn’t know. CORALINE: It should be. Yeah. VAIDEHI: Because you’re like, “I didn’t know it then, but I wrote a blog post about it,” or “I took on this feature and I learned this thing. Yeah, I didn’t know it then, but look at all the things I had to go through. And now I have a firm understanding of it.” CORALINE: Yeah. JOHN: Yeah. I’ve found that for me, it’s sort of a curve. So, the more recently the code was written, the more I’m attached to it. And then after probably a year or so, it’s down to zero. And I’m like, “It could have been anyone. I don’t care. I’ll tear it out.” But when it’s more recent, especially if you’ve spent a lot of work on it, I definitely get attached. And I had an experience where three months prior I had rewritten this whole thing and put in a new feature and then a developer came along after it had gone into production and avoided most of what I’d done and rewrote this whole other section. And I was like, “Aw, I’m really pissed” for like a week. Because I was like, “Aw man, I just put that out there.” But what I had done was written this whole thing in isolation and not gotten any input from the rest of the team about what the needs were going to be. So, it didn’t do what he needed it to do. So, of course he rewrote it. And once I realized that, I was like, “Oh yeah, well we’re better off now.” And I knew I was being weirdly reacting to it. So, I didn’t talk to him about it. I was just like, “I’m going to let this settle down. And there’s nothing to do about this. I just have to deal with it.” JAMEY: I think that’s so true and it’s not just with your coworkers. Like when I’m thinking too hard about, “This is the code I’m writing and it’s my code,” I’m not thinking about the people who are going to use my software either. So, when my CS team or whatever comes back and says like, “This is what the customer wants,” and I’m like, “Well, that’s not what I wrote.” [Laughter] And I’m like, “They should want something different.” And it’s like, no, I should have written something different. And it makes, if you’re too attached to it, it makes it really hard to be like, “Okay, well this is wrong. And unfortunately I sunk a little bit of time into it. But I have to just do my best now to fix it.” CORALINE: And I think John brought up an interesting point and that is the code we’re most attached to is probably the code we wrote in isolation. And software though, good software, comes from collaboration. And it’s a matter of people working together and coming together to solve a problem. And if you’re emotionally attached to the bit of it that you wrote, you’re actually excluding other people from participating in that creative process. And if you’re letting your ego get in the way and so strongly identifying with your code, you’re preventing that collaboration from happening. And your code quality is going to suffer as a result. JOHN: Yeah, that’s a great point. DINAH: I think what’s interesting that a lot of you mentioned attachment, because I almost feel like the opposite about my code sometimes. Like, sort of shy and ashamed of it in a way, which is really sad. Because I think a lot of people do start to see writing code as more of an artistic thing. There’s not necessarily like a right way to do it but there is a preferred way to do it depending on what company you are at or what language you’re working in, things like that. And similar to this idea of code being art, I think art is never really done. I know that when I’m working on a piece of writing, whether that’s an essay or poetry, I have to time-box myself if there’s a deadline, because I’m just going to keep working on it until the very last minute. And I’m not even necessarily making it better. I’m just making it different. So, similarly I think because usually we work in code in the context of industry or even not in the context of industry, we want to deliver something, we kind of have to cut ourselves off and say, “Okay, well this is where it’s going to be for today. This might not necessarily be perfect, but I have to deliver something meaningful to consumers or to users, whatever that might be.” And as a result, I almost feel like I want to apologize because there’s so many things that could be better. There’s always things that could be better. But I didn’t necessarily have the time to do all of those things. And I almost want to give myself a crutch and say, “Oh, well you know it would be more perfect if I had a million years to really craft it.” But I don’t really think that’s a good thing. CORALINE: Yeah. I think you make an interesting point Dinah about the relationship between code and art and never being done. One of my favorite books is this Russian classic called ‘The Master and Margarita’. And interesting story about the author. The author was on his deathbed making revisions to the book. So, the book was never finished, but it’s perfect. The book is good enough. It communicated the ideas that he was trying to get across. And finding that point where our code is good enough is hard if you can’t separate yourself from the code. Because you’re like, “I know I can do better if I just keep working on it, I can make it a better expression of who I am,” when as long as you’re communicating what you need to communicate to other developers, and you socialized the innovation you brought to the code, it doesn’t matter. Beyond a certain point, it doesn’t matter anymore. DINAH: Yeah, absolutely. And I think one of the issues that comes up when I am a little bit too, what is the word here, critical of my own code is almost like I jump at the opportunity for someone that I perceive to be more experienced or just a better developer in general, I want them to evacuate whatever I’ve written for their interpretation of it, even if sometimes their interpretation isn’t necessarily better. I almost just want to trust them because they seem like they know what they’re doing, like they carry an air of confidence that maybe I don’t carry around the code that I’ve written. CORALINE: I can tell you, after 24 years of developing software, you always feel that someone else knows better. JOHN: Oh, yeah. CORALINE: And you’ll always doubt yourself. [Laughter] So, be prepared for that. [Laughter] I don’t think they teach that in bootcamps or in colleges. But you’re always going to feel like your code isn’t good enough and you’re always going to feel like there’s someone who’s better at it. And someone – you’re always going to devalue your own work. It really – confidence is hard to come by. And a lot of people have swagger, but they don’t have confidence. JAMEY: I think we’re starting to circle around this issue. A couple of people have mentioned things that have made me think of it, of code review, and how having different types of relationships with their code, code review will feel very different. Because I think if you are feeling very emotionally attached to something, then someone coming in and earnestly trying to help you make it better can feel like an attack on you personally. And it makes it really hard to do constructive code review. But then what you were describing is also not super constructive code review, to be like, “Just tear it out and replace it.” And I think there’s got to be some middle line that we’re walking hopefully where we can maybe talk constructively without letting our emotions get too much in the way, I guess. It’s hard. That’s a hard thing for me to say, because I think that people’s emotions are very important and you should cater the way that you speak to them and interact with them to that, because that’s how you respect other people. But I guess that’s the question I’m posing to everybody. What do you think? Where do you think that line is and how do you think is a healthy way to do code review? CORALINE: I actually, I’ve been working on the interviewing and recruiting process at Stitch Fix lately. And we had an opening for an engineering manager. And we have a certain level of technical acumen that we want a manager to have. But they’re not necessarily writing code every day, right? And we were putting all of our candidates through the same take home coding exercise. And what I realized that we should actually be doing, and this is part of my strategy for evaluating people in terms of how well they would fit in with our values as opposed to the technical scope that they had – I designed a code review exercise. So, the scenario is that an early career developer has been asked to extract a service and this is their best effort. And you are going to do a code review on their code. And that lets us see how compassionate is the person? Are they making valid critiques but couching them in a way that’s not going to make the person defensive? Are they good at technical communication? And also, there’s some obvious errors that they can point out. But it’s on all of us to be compassionate in our code reviews because people do have those emotions attached, for better or for worse. And it doesn’t take that much more effort to be compassionate. It really doesn’t. VAIDEHI: I really love that idea. That’s such a fantastic idea. Because it’s interesting when you were mentioning the idea of newer people in the industry thinking that someone else is more experienced. Because I’ve definitely been in code review situations where the person whose code I’m reviewing has years more experience and I’m like, “Oh, I’m like a mid-level engineer and I know things.” So, I’m asking legitimate questions because I’m curious. And because of their own attachment, instead of taking it as an opportunity to be like, “Oh actually, so my reasoning for making this choice technically was this,” it can very easily swing towards, “Oh, this is just the way I’ve done this. This is what you do,” and then shut down, right? And it’s like, that’s such a great opportunity to see, can you take critical feedback from others? But also, can you compassionately explain your reasons and care about the code your writing? But also see and have room for, have an open mind to be able to change it. Because as you mentioned before, it’s a collaborative thing and code reviews should be collaborative, because the codebase is going to be touched by everyone. CORALINE: Yeah. VAIDEHI: The code you write shouldn’t be in isolation and the code you’re reading is not going to be just yours, either. And I think if there could be a tone set with code reviews where it’s like, “This is actually a collaborative thing we care about, so no one’s here to attack each other. We all care about this thing so we’re all trying to level it up and lift it up as much as we can together.” It’s never about the person. It’s more about, “We share ownership over this collectively.” JAMEY: I think the problem is that a lot of people have been in situations in the past where people are trying to attack them. And because that’s happened to them, you’re like coming from this place of defensiveness from the offset, sometimes. JOHN: Yeah. I love that idea and it seems like that would apply to even down to juniors to see how their compassion is working with other people. But I find myself actually preemptively indicating my willingness to take input when I put PRs out. I’ll say, “Hey, this is a thing I came up with,” and sort of actively soliciting, “If you think this is the wrong way of going,” and saying, “I’m okay with you saying we have to re-architect this whole thing, not just point out that the semicolons are wrong.” CORALINE: Yeah. And that comes down to trust, right? JOHN: Yeah, yeah. I definitely trust my team very deeply. So, I’m able to say, “Bring it” and know it’s going to be good. VAIDEHI: And they probably trust you, based on all of your PRs and the tone that you set of, “I’m open to it.” They probably trust that, “If I ask a question, I’m not going to be criticized or be told I’m too stupid to understand.” I can ask a question knowing that I will get a compassionate answer and I’m not going to be [made to feel] little by asking that. CORALINE: So Nick, you’ve done a lot of open source work. And I’m curious how all of this translates to the open source world. I think that a lot of large and successful open source projects – of course anyone can open source anything, but the big ones – they seem to have names attached to them. They seem to have egos attached to them. And do you think it’s more prevalent in open source for people to have this, “My code is who I am and don’t you dare criticize it,” kind of attitude? NICK: Yeah. I think that’s definitely a component. I think it’s very easy to tell when someone has internalized humility as a core value that they work with or they don’t. And it’s like super obvious. And what I’ve recognized, I think one thing that’s made a huge dent on this is obviously the Contributor Covenant and having a set level of, “Hey, this is the baseline. We’re not going to tolerate personal attacks. If there’s a discussion or a disagreement, here’s how we’re going to handle it.” And I feel like a few years ago, there wasn’t a way. There wasn’t a language to talk about this kind of stuff. CORALINE: Yeah. NICK: That’s gotten better over time. The thing that I’ve been just going back, stepping back a bit, this is still related to how we deal with interactions especially with pull requests, is that sometimes I feel like these – I over-analyze the small parts of these day-to-day interactions. And these are things that we look at every day, such as, “Okay, when I approve versus request changes,” which that’s so little. That’s literally one little radio box, but you get to see a big red X next to all that stuff you just did. Well, instead of saying, “Okay, hey you must change this line to be in the way that I want it to,” instead of being like, “Why did you phrase it that way?” I would use all these other stuff. There’s this, use an example. I’ve been trying to look at those, the small interactions. And those obviously apply to more bigger, open source scale as well. CORALINE: You just gave me a good idea. And I can’t ask GitHub to do this, because I’m a persona non grata. But maybe instead of the big red X, if you request changes there could be a dialog bubble. NICK: Yeah. I’m not a fan of that X. [Laughter] There’s something about it. Everything else about the pull request process is so great. We’re working together. And it’s like, “Nope. You cannot do this.” Like, yeah. CORALINE: Yeah. Because if you’re requesting changes, you are opening a dialog, right? If you’re doing it right. NICK: Correct. Yeah, yeah. It’s just so weird how just the tiniest little interactions can actually spawn – especially if you’re not face-to-face with that person, and that could be like, “Oh, they’re upset with me. Something’s up. I think they’re…” Those little things I think matter a lot more, especially when we just kind of gloss by them a lot. CORALINE: And especially I think we encourage early career developers to get involved in open source. And we’re exposing them to these really difficult emotional situations. And we’re drumming this idea of meritocracy where your worth is directly tied to the code that you’re writing. And that’s putting a lot of pressure on people. And that also puts pressure on the maintainer to say like, “Well, this code could be better, but I don’t want to hurt this person’s feelings. They’re a first-time contributor. I’ll accept that.” And instead of the dialog, we end up with walking on eggshells around each other. NICK: Yeah. JAMEY: That’s a great point. I didn’t think about it going the other way and accepting code that you wouldn’t have. That’s interesting. DINAH: Yeah, I think – I guess one thing I would add about open source pull requests are you could establish a really great working relationship with other maintainers, especially if you’re a frequent contributor. And then if you happen to work on a pull request that for some reason is maybe a little bit more higher profile, if it’s one of the main headlining changes in the next release of Rails, for example, a bunch of people will just descend on that pull request and make comments, even if they’ve never really looked at Rails internals before. And on the one hand, that’s definitely something we should encourage because it means people are getting more involved in open source. They’re taking the time to read through that pull request hopefully. But on the other, sometimes those individuals may have never worked in an open source project. They may have never worked in that particular project. So, they’re not that familiar with that particular project’s tone and how the people in that project communicate with one another. CORALINE: I get asked a lot how to find welcoming, inclusive open source projects. And of course, the first thing I say is look for a code of conduct because that’s a signal that they actually care about people who are contributing to the project. But the second thing which is just as important, if not more important, is how are they following through on it? So, I encourage people to go to the issues list and go to the open pull requests and see how the maintainers are communicating with the people who are contributing to the project. Because that’s – the proof’s in the pudding. If they can have adopted the Contributor Covenant but they’re assholes, you don’t want to work on their project. So, get a sense of the tone. Get a sense of how people are interacting. Is this – code is social, you know? So, is this a social situation that you're going to feel comfortable in and feel safe in? NICK: Yeah, it’s weird to think about – I feel like for a lot of first-time contributors, they’re so worried about getting all the details right. It’s like, “Oh, I must fix this exact problem. It must be in an exact way.” But you’re dropped into this situation where everyone else is like, “Whoa,” like there’s a potential threat of like, “Okay, this might open up a patch. Or this might open up a hole for security. This might not do what it’s intended to do.” There’s always risk from either side. And just the fact that this is just one component of it that people didn’t consider for the longest time of like, how do we work together in a way that is human? [Laughter] And now, I think it’s getting better, but slowly. You have to actively care about it. You have to actively be someone who’s pushing it and displaying those values. And if not, people walk away. And it’s because there’s so many other opportunities to take. CORALINE: Yeah. JAMEY: It’s interesting to me in general that in open source, open source doesn’t work unless you have contributors. And everyone’s working on stuff because they care about it and because they want to be a part of it. And it doesn't work if you don’t have that. So, it’s hard to understand why you would want to be hostile to those people. [Chuckles] Because you need that. NICK: Right. JAMEY: And if you drive away all those people, then you don’t have a project anymore. NICK: Right. Well, I think we touched on that. We were like, “It’s my code. It’s my line. Why are you touching it?” VAIDEHI: It’s the ego thing. NICK: Right, right. It’s a total ego trip. And you may have been, “Okay, I’ll slap a license on this and get it out there,” but if you really want to make a dent in things and if you want people to help out, you have to be a social creature. You have to welcome change. You have to welcome people playing in your sandbox. And there’s a lot of people who are just not comfortable with it. JAMEY: Yeah, and it’s self-defeating otherwise. NICK: Right. CORALINE: And that’s where meritocracy comes in too, right? Because we have a Chad who had an idea for an open source project and it took off. And Chad, since Chad self-identifies with that code so much, Chad is going to be defensive about it. And Chad is going to be like, “I am successful because I am the best person. Because my code is the best.” And there’s like this elitist attitude that Chad might develop that will be off-putting to other people, but maybe Chad gets paid by his employer to do open source. And so, a toxic project gains a foothold. NICK: I think this touches on another point that I don’t think open source projects do and I think this is related wherein it is an act of creativity and I think of I think a valid open source way to just kind of, “Here’s the code. And then I’m done now.” It’s out. It’s out there. And we don’t have a way currently of saying – this has been true for especially in the Ruby community for years such that like, “Okay, here’s my gem. Here’s my code. I’m done with this.” And typically you’ll get people coming back that are entering the project years later and being like, “I use this now. My whole business is dependent on this.” And now you get like, especially if you’re a maintainer, you get an email. It’s like, “Why aren’t you around, you jerk?” [Laughter] And this life cycle is not something that we consider. We consider a lot about getting into a project, but we don’t consider the other side of it, or just the creative act of you’re willing and able to give it up but you don’t have the time to help grow that. And hopefully you have the wherewithal to be, “I’ll give it to someone else and then they will grow it.” But a lot of times, we don’t think about the entire life cycle. I’d be curious if others have thoughts on this life cycle. Everyone’s hit that dead project before and wondering how to deal with it. DINAH: I just feel like it would be so rude if someone emailed a maintainer and was like, “Why doesn’t this have updates? You said free software. Come on, man.” [Laughter] What’s with that sense of entitlement? JAMEY: Yeah. I was going to say, it turns out that people are entitled about all sorts of things in life. VAIDEHI: I think it’s a little bit a reflection on the creative process too, right? Where if you talk to writers, the first book, or blogging or any type of content creation, starting off you’re like, “No one’s going to read this. What if no one reads this? What if no one cares?” And then people start to care and then they have demands. And now you’re like, “Oh my god. There are demands. Oh my god. Now everyone cares. Now, I have to meet all these qualifications and expectations.” And it’s like, it is the same problem. It’s the other side of the coin, basically. And I think it’s with all creative pursuits, but I think in open source it manifests itself in a maybe not always productive way. NICK: Yeah, totally. VAIDEHI: I have a question that I don’t know if we touched upon it yet. This has happened to me at least once before where I have worked on code that I felt emotionally attached to but also other people had worked on. And I was like, “It’s not just mine. We’ve worked on it and we all feel really good about it.” And it was for a product. And it never saw the light of day. It was completely killed. And I’m curious to know if you’ve ever worked on features, or maybe even in open source where you have put in so much love and effort into something and it’s kind of the opposite of what you were saying Jamey, where you don’t even get to show it to anyone. And it’s just dead. And how do you deal with the reality of that? Number one. And two, the emotional I guess baggage that you have to deal with that nobody necessarily else on the team might understand. CORALINE: I think it ties into something we touched on earlier actually. You have to define your success criteria for writing code. And maybe for a project that never saw the light of day, maybe you can think about how it improved your abilities, how you demonstrated that you were able to solve a particular problem, look back on what you learned. Commercial success isn’t the most important measure. And I have a lot of – I have 25 Ruby gems. And hardly anybody uses them. I’ve never, with the exception of Contributor Covenant – it’s the only open source project that I’ve done that actually caught on. But all of the gems that I’ve written and published, I have pride in the craftsmanship that I put into it. And that’s enough. And it’s a record of my developing skill with Ruby and it’s a record of the problems that I was interested in solving at a point in time. And I’m satisfied with them. And I’m happy to have them on my resume. And I don’t care about their commercial success or popularity or how many stars the GitHub repo gets or anything like that. It’s I have a sense of accomplishment from having solved a problem. And that’s what motivates me. And we live in a capitalist society so we have values attached to monetizing our work. But I’m not in it to like, “I want to make the best product I can make. I want to work for a multimillion dollar company.” No. I’m in it because I love the creativity that goes into the work. And that’s where I derive my satisfaction. JAMEY: I think it’s actually more than that. Like you said at the beginning of that, how do you define success of your code? And I think it’s like, how you define success in your life and how you define happiness in your life. And if your work can be part of your overall success and happiness, then that’s really great. And that’s a privilege because that’s not the case for a lot of people. But if there are other things in your life other than your work that bring you success and satisfaction and happiness, at the end of the day, we do tech for our jobs. And maybe we also do tech for our hobbies. But it’s not the only thing hopefully, it’s not the only thing that’s happening in our entire lives as a person. CORALINE: Are you saying Jamey, that we don’t have to spend 100% of our waking hours writing code in order to be successful? JAMEY: I know. It’s a crazy idea. But I just thought of it right now. [Laughter] CORALINE: Wow. This is life-changing. I can’t. JOHN: I actually did a talk recently, just last month, about something very closely related which is when you get stuck on those horrible long bug hunts where you think it’s going to be a half hour and it’s two, three days, a week, or whatever – and those usually feel really, really horrible just because you think, “I wasted so much time. I didn’t get my sprint done,” all those things. But if you look back at that time, you realize how many things you learn that you didn’t know that you had to do to get to that answer. And you learned a ton of things that got you to the answer. You also learned a ton of things that didn’t solve your problem, but that you know now. You read a million blog posts and Stack Overflow and all these things. And now those extra seeds of information are in your head. And so, trying to look back and see that value there makes it feel a ton better. JAMEY: I like that. It’s like intense mandatory learning. [Laughter] JOHN: Yeah. DINAH: That sounds so fun. [Laughter] CORALINE: Oh, crap. It’s 10:25. I better learn something. [Laughter] JAMEY: Quick. [Laughter] CORALINE: Quick. DINAH: Yeah, I definitely agree. I think one of the things that I try to always remind myself, definitely in work but in all aspects of my life, is that you can only ever control your reaction to a situation. You can never control the situation. Well okay, sometimes you can control the situation depending on what it is. But maybe one of the reasons that the project didn’t ever see the light of day was something else out of your control. And in my personal life, there’s way more serious things like a loved one being ill or something like that. So, I always try to find a way to make peace with what happened and try to put a positive spin on it in all of the ways that everyone’s kind of already mentioned. And I think this is especially true for open source. Like if you’re working on a project, you really have to accept that you might put a ton of hours into a change, into a patch, and it works but it won’t get merged because of a difference of opinions, because what you think belongs in a project, the maintainers or the core team doesn’t see that feature as something that fits with the rest of the project. And if you haven’t made peace with that idea, I wouldn’t say that it’s like a requirement before starting in open source. But it’s something you should probably think about. Because it happens really frequently. And it’s not from a place of malicious intent by any means. I think just earlier in this conference, someone recommended a great talk to me by I think it was Katrina Owen about how difficult it is for her to say no to pull requests that she gets. So, understanding that it’s equally hard for the maintainer or the core team or whoever it is to say no because you’ve put in all this time and you’ve shown that you’re interested in this project, but it’s more responsible in the long run for them to maybe stay true to whatever vision they originally had and not accept it. And I’m going to find the name of that talk. It’s called ‘The Bait & Switch of Open Source’. CORALINE: I think it’s really interesting you said talking about situations that are beyond your control. My coauthor Naomi Freedman gave me some advice when I was going through a difficult time. And what she said is, “Live every day as if you had chosen it.” And I think if you find yourself in less than optimal circumstances, if you put a lot of work into something and you’re getting no love from it, if you ask yourself, “Well, why would I have put myself, why would I have chosen today to turn out this way?” you can find the value in the experience. And instead of letting it drag you down, you can say, “Oh, but I learned something really great,” or, “Oh, they didn’t accept my pull request. But I leveled up.” Or, “Now I know something about how to contribute to this in the future.” And that helps you find the lesson. DINAH: Yeah. NICK: So, as someone who’s been on the flip side of this, as someone who has said no, I can tell you that it hurts equally as much. And it really stinks because you know that this person did so much work. And they really put their heart into it. But if it just doesn’t fit, or they just went off on a tangent, it’s like what I’ve tried to is try to find some other way that that can be useful. And that’s what’s been – I think that’s more the pain for me because I don’t want to see that hard work go to waste. But that’s also really difficult, to be like, “Oh, this could be a separate, in our case, a gem. This could be a separate website. Could you please publish this, just not here? Elsewhere would be cool.” [Laughter] And then if other people think it’s cool, then that’s great. But I just can’t do one extra thing. And I think that’s a lot of what it comes down to, too, is that’s one extra thing I need to worry about. And there’s been a lot written about this, about when you’re writing a new feature, especially a feature, it’s like you’re giving that work, that labor, to the maintainer now. JOHN: Free as in puppy. NICK: Right, right. [Laughter] Right. It’s like, please use this box of kittens. You’ll really love these kittens. Please take a kitten. You just need one more kitten. [Laughter] You can deal with it. Just buy some more food. [Laughter] VAIDEHI: It’s the same. NICK: Yeah, it’s definitely the same. CORALINE: I had an amazing experience with open source when I first came into the Ruby community. There was a gem called Rcov, which was a code coverage tool. And I loved the idea, I was really into TDD at the time – I moved past it – I was really into TDD at the time and I saw code coverage as an important metric for quality. So, I would use this Rcov gem. But the thing that I hated about it, and I looked at the code and there was brilliant stuff under the hood. But the output was hideous. The output was unusable. And I was like, “I can fix this.” So, I completely rewrote the output of Rcov. And it took me two months of free time to completely re-architect the way that reports were generated. The entire reporting infrastructure. And it’s this massive PR that I submitted. And Aaron Bedra was in charge of the project at the time. And bless him. He was like, “Coraline, thank you. We can’t use any of this. Unbeknownst to you, we had been reworking the internals of Rcov so that we can release a new version.” But the thing he did that was so remarkable is he said, “Let’s pair. And let’s take the idea of what you're trying to do and let’s work on it together in a way that I’m comfortable maintaining and that’s respectful for my design.” And that was so amazing. That was such an amazing experience. And now of course, the tool is SimpleCov. And SimpleCov does all the things that I added to Rcov, which is – I’m like, “My idea lived.” Uncredited, but my idea lived. [Laughter] But yeah, that was such an amazing open source experience. And that could have gone so wrong. And that could have poisoned me in terms of my expectations for working with open source projects in the future. This, the compassion that was demonstrated there was remarkable and was so welcome. VAIDEHI: And, sorry. DINAH: No, you go. VAIDEHI: I was just gong to say, your comment about just suggesting another place, it’s such a little thing but it can still validate someone’s emotional attachments. Like it’s not that it’s bad. It just doesn’t – it’s not a good fit for this. And such a small thing, but it makes such a huge difference. CORALINE: And again, like I said earlier, it’s not hard to be compassionate. You just have to wait a beat. You have to give your heart a second to catch up with your mouth. JAMEY: We’re talking a lot about compassion right now. And I think it’s interesting because this whole idea of being afraid to say no or having complex emotional feelings about having to say no, I think if you’re having that kind of difficulty in the first place, it’s because you already have some of that compassion. Because if you have none, then you’re just like, “Nope. I hate this. Goodbye.” And that’s easy to say if you don’t care how the other person feels. But if you care how the other person feels, then it’s hard to say that. CORALINE: Yeah. NICK: This is reminding me of before, earlier in the open source world there was this term of a fork. And I feel like recently this change, the grounder for the compassion of this as an action changed literally because of GitHub. It used to be that a fork of a project, if I was going to fork your project things were bad. I was like, I had a fundamental disagreement with you. You didn’t accept my patch, whatever it was before then, and it’s just like I am going in a different direction and I’m going to put my stuff in a different place. I want my own sandbox. Adios. And like… JAMEY: I’m going to have my own party. NICK: Right. I’m having my own party over here. JOHN: Yeah, the community is splitting. NICK: Right. And I remember when there was like first, you can just fork any repo. And I remember discussions about people were freaking out. Because they’re going to have any discussion when there’s no lack of compassion, when it’s one button to just be in disagreement and start publishing something different. People… CORALINE: And start competing. NICK: Right, and start competing. People were going to lose their minds. And it didn’t happen. And it didn’t happen because I think people realized the social cost of doing that is immense. Like, you’ve really got to have it in for someone. But I think it still does happen in several ways. Like this just happened with Node. Node went elsewhere. This happened in our community with Rails and Murb and it came back together. But there’s always this social aspect of compassion is still deep with us. We haven’t solved those problems yet. JAMEY: I think it’s interesting how at the beginning of this discussion we were talking a lot about: we should fix this problem of being overly emotionally attached to your code because it makes for worse code. And as we’ve had this discussion it’s slowly morphed into like: we should solve this problem of emotional attachment with our code for ourselves so that we feel better and we’re having better lives, I guess. And I think it’s interesting how that’s not maybe what was on the top of our minds when we first started talking. But it’s what it came around to. CORALINE: Yeah. And in a meritocratic system, there is no attachment, right? Emotions are bad. You’re a robot that produces code and you are judged by the quality of the code that you produce. And what this conversation’s done is we’ve acknowledged that we have an emotional attachment to code. And we don’t want to become codependent on our code. [Laughter] We want to have a healthy relationship with our code. And that means making room for emotions but in a healthy way. JAMEY: I agree. And it means talking it out and being willing to talk it out with other people, too. CORALINE: Yeah. Code is social. That’s what this podcast is about, right? Code is social. Code is solving people problems and people problems are communication problems. And if you’re not, if you don’t have emotional intelligence, you’re not a good communicator. NICK: It’s been interesting to think of this in terms of how open source projects communicate now and how that’s changed over time. And I feel like now there’s different forums, quite literally forums in which we communicate. And there’s different ways and modes to interact. And the GitHub side is the very, “I’m doing work.” I’m doing work here, I need feedback on work. But then there’s like the social side. And historically, that was filled by IRC. There was a chatroom that everyone would dump into. And now it’s Slack. At least, that’s what I’m seeing, is most places have Slack. And I’ve been curious to watch how projects, if projects become more insular because of the tools they choose which inherently have these culture of values built into them wherein no one else in the outside can see this work. And historically Rails has been like this. Rails has always been internal. There’s always been an internal chat. There’s never been an external, as far as my knowledge goes, room for others to look into these internal communications. And the same deal goes with mailing lists where there’s internal core mailing lists for all the big projects in open source, and external ones too. So, I’ve thought a lot about this, and especially when deciding: how does one set up communication for a project? How do you – do the tools you choose reflect some inherent values that the project has? And it’s like, because I’m choosing Slack for example, does that mean I get all the hip people but not necessarily the people that I want to keep their communication public? If I choose just a mailing list which is the historical, what everyone has always used, do I seem like I’m not on top of it? I think a lot about some of this stuff. Especially Slack. Slack is – I could talk for an hour about Slack. JAMEY: Can I tell a story about Slack? NICK: Sure. JAMEY: When I was at my first conference a few years ago, someone was talking about Slack and I’m like, “Yeah, I have 17 Slacks now,” or something like that. And they were complaining. I was like, “Pants? Slacks?” [Laughter] So, that’s more character development for me. [Laughter] NICK: That’s how I feel that it is when someone has the 10 Slacks open. It’s like, you’re carrying around 10 pairs of pants. [Laughter] Yeah. DINAH: So, that’s how they came up with that name. NICK: I hope so. [Laughter] CORALINE: I think it’s very clear they only designed with one Slack in mind. NICK: Right. There’s only one. Yeah, most people just need one pair of pants. CORALINE: There’s no [inaudible]. I don’t think they anticipated the use case of 15 different Slack communities. NICK: No. And I feel like at some point they were like, “That’s too many pants. I’m sorry.” I just love this metaphor. [Laughter] JAMEY: That’s what you should take away from the show. Sorry. CORALINE: You have your pair of jeans. What else could you possibly want? DINAH: I also want to add that I’ve seen some people say that they think in open source, all communications should be public because it means that everyone can see it. Everyone can contribute. And I see the value there. But I also think for a new contributor, that’s terrifying, for you to share your ideas not really knowing whether or not the maintainers or other people in the community would be interested, to put yourself out there with so many eyes on you. That’s a lot to handle. JAMEY: That sounds like it’s kind of what happened to Coraline with the project she described. CORALINE: Yeah. Yeah, it can be very intimidating. And you as a project maintainer might hold core values of openness and inclusivity and welcoming and being patient with new contributors. But in an open forum where just anybody can sign up, the tenor of the community can change. And you won’t have any control of it. People could be scared away from your project because of the loud angry person who hates noobs, right? JAMEY: And that person is always louder than anyone else. CORALINE: Yeah. The negative people are always louder. JAMEY: We’re getting this motion from the back of the room. It’s hard to see behind all of the 150 people. [Laughter] CORALINE: Peering through the telescope. Seeing Mandy at the back of the ballroom, she’s signaling to us to wrap up the conversation. So, I really enjoyed this and I really enjoyed the perspective that our guest panelists brought with them today. JAMEY: Definitely. CORALINE: I think this is something that we’re going to touch on in future episodes because it’s like, kind of front and center. JAMEY: I think it’s really central to the entire concept of Greater Than Code. You aren’t your code. There’s more to it than that. And it’s more complicated than that, as everything in life always is. CORALINE: I think our ideas on this subject are going to evolve as we talk about it, too. JAMEY: I agree. Well, thank you everyone for coming. NICK: Thank you. JAMEY: Thank you for listening at home. Thank you to O’Reilly and to Cloud City and to RailsConf for letting us do this. CORALINE: If you enjoyed this conversation and you want to continue the conversation or participate in conversations like this where we actually dig into what it means to produce code and what it means for us personally, we encourage you to go to Patreon.com/GreaterThanCode. Pledge at any level. Pledge a dollar and you get access to our exclusive Patreon-only Slack community. And the discussions there are wonderful. The people there are wonderful. They care about the same things you care about as a listener. So, please consider donating and come and join us. And we want to hear from you. We want to hear your thoughts and your ideas. And they do inform the things we talk about. We are a community and we care about you. So, come join us. Thank you. [Applause] CORALINE: That was so much fun. JAMEY: That was really fun. NICK: Yay! Thank you.