JOHN: This episode is brought to you by Charles Schwab - a modern financial services firm that stands apart from the industry, where you can go as far as your ambition and unique talent take you to create a career worth owning.

Hi Jyothi, thank you for joining us today. As a person with a tech background, what made you consider working for Schwab?

JYOTHI: I think although it's a financial company, it is technology driven. They are up on all the technologies, and pretty much everything that's out in the market, and the standard to be used, they are there. I think, yes, their domain is finance, but I think they are pretty technologically strong, as well. I would like to tell other programmers who think that Schwab is not a tech company, you are wrong. They have a very complex tech stack, and it is going to be really interesting and very fulfilling to work here.

JOHN: To learn more about the technology career opportunities at Schwab, visit SchwabJobs.com. 

CORALINE: Hello and welcome to Episode 130 of the Greater Than Code podcast. My name is Caroline Ada Ehmke. I'm joined today by my fellow panelist, Sam Livingston-Gray.

SAM: Hello, hello. And I am pleased to announce that with us today is John Sawers.

JOHN: Thank you, Sam. And I'm here to introduce our guest, Britni Alexander. Britni was born and raised in Atlanta and still lives there. She's a Software Engineer for four years, concurrently working at MailChimp. She's a former co-organizer of Rails Girls Atlanta and RailsCamp South.

Previously, she was in retail, apartment leasing, martial arts, Army National Guard, and Disney princess children's party performer which is a pretty great list. Welcome to the show, Britni.

BRITNI: Hi, thanks for having me.

CORALINE: So Britni, you know what's coming.

BRITNI: I'm ready.

CORALINE: All right. What's your superpower and how did you develop it?

BRITNI: I'd say my superpower is resilience. I think over the years, I have definitely had a lot of failures. And early on whenever I would fail at various and sundry things, I would just kind of wallow in it for days, weeks, months. Eventually, I started to just let myself really fully wallow in it for one or two days and then start making a plan for what I was going to do next. I remember in college, I was in ROTC and I was planning to do a military career. I was going to go off and be an officer and I got this [inaudible] pretty close to the end and it kind of killed my whole plan. I was real mad about it for a couple days and by then, I had already developed a great deal of resiliency and I just started looking for something else to do. Eventually, that led me to programming.

JOHN: You feel like that was something you developed actively or just sort of evolved as you got better and better at coping with them?

BRITNI: I think it's just something that you have to foster as you deal with things. I do think it's something that you have to think about. If you are telling yourself that you can keep going, then you might just hold onto things for years. And there's definitely been things that I've held onto for much longer than I would now, I think. But the more I fail, the better I get at doing it.

JOHN: At failing?

BRITNI: Oh, yeah. I think a lot of times, when people fail, they and I don't see it as the opportunity that it is. Looking back, it's easy to see with hindsight how terrible the things that you wanted to achieve would have made your life or your relationship to blur and you think, "Oh, this is going to be great." And then you look back and like that person turns out to be terrible, I feel like, "Oh yeah, I dodge level it." And I think it happens too at work. I was working at a pretty terrible company and got laid off, and the direction that the company went pretty sour. Because of that, I ended up at MailChimp. I got to travel with my mom all summer, makes memories with her. And so, I think that if you just sit in that spot of failure for too long without seeing what else there is around you to move on to, then you're missing out on a lot of great things.

JOHN: But what if you don't know how to do anything but wallow?

BRITNI: I think that's when you have to lean on people around you. I definitely am not an island. And whenever I was early on being just wallow girl, there are people around me telling me to lay all the opportunities I had around me. At first, I didn't believe them. Nobody ever really believes people when they're telling you how good your life is in the middle of something crappy. But eventually, their voices start to break in. And so, if you're a person who's around somebody who needs some resilience, just keep cracking it at the wall and eventually your voice will break in.

CORALINE: I don't know if this will make sense, but do you think failure is a 'No, but...' situation or a 'Yes, and...' situation?

JOHN: Ooooh, good question.

BRITNI: That is a good question. I think at first, I would have said it's a 'No, but...', but now that I'm so much more resilient, I think that it's a 'Yes, and...'. Early on, I would have been hanging out in that 'no' and emphasizing that but now, I see that it's more of a 'yes, this job didn't work out but think about it, you really didn't want it to any way deep down'. And now, you can do all this stuff.

JOHN: Yeah, it's a really good reframing. I like that. It seems to me that maybe the thing right between those two is acceptance that seems to be the difference between no and yes. You have to accept what happened before you can end the next thing.

BRITNI: Definitely. 

CORALINE: In the talk I gave about emotional intelligence at RailsConf last week, I talked about sadness being the result of an unmet expectation and you get a negative outcome when you hang on to that expectation that leads to all sorts of more negative feelings, whereas if you kind of reorient yourself and let go of that expectation, that allows you to move forward? Is that tied in with the kind of resilience you're talking about?

BRITNI: I think definitely, especially in the professional world and with relationships of people, you do tend to build up a lot of expectations around the way something should be. And it's interesting that your talk was about that because I recently finished reading this book Awareness by Anthony de Mello where a lot of it is just talking about accepting things as they are and really seeing things as they are. And the sooner you can do that, the sooner you can give yourself permission to be happy. We place a lot of our happiness on external factors, the way people treat us, the way we think that they think of us, or the way that a company is or isn't meeting our needs. Whereas if we decide we're already happy and whatever the external circumstances are to that, then it allows us to let those circumstances just flow through us. He even go so far as to say that even whenever he's depressed, he knows he's depressed so he doesn't accept that as being who he is. He accept it as being part of what he's experiencing right now and he can kind of watch it go through him.

CORALINE: That really, really resonates with me. I had a bad period last year. It came on pretty quickly. It felt like all the color had been drained from the world, I had no energy. I was crying all the time. And I had an appointment with my therapist and she said, "It sounds like you're in a depressive episode." And I like smacked my forehead and I was like, "Of course, I'm depressed right now. That's why I'm experiencing this." And just naming it allowed me to introduce some distance. And then like you said, it became something that I was experiencing, not something that I was.

JOHN: Yeah, that is such an important distinction. I think with depression and anxiety and those sorts of things in particular, but I think with all feelings, if you don't consider them to be part of your identity, then you don't hold on to them and you don't also try and plan your life around what you're currently feeling rather than realizing that it'll pass. And then other things will happen.

CORALINE: That being said, I think it's important that we acknowledge those emotions. So if we try to ignore them, that's really not a healthy outcome. Rather if we acknowledge them and say it like, "What do I want to do with this?" An analogy that a friend of mine shared with me was think about if you're in a train station and you have a destination in mind. And a train pulls in and that train is an emotion. It might have been unexpected, it may not be the train you're looking for but you have a choice. You can ignore the train and pretend that it doesn't exist which isn't really right or true or healthy, you can get on it and forget about your destination and just sort of end up in the middle of nowhere or you can get on and ride it for as long as you need to and get off at your destination. And that metaphor really works for me because I have a problem with acknowledging emotions for a long time. And now, thinking about that metaphor, that kind of puts me back in control where I'm not denying the existence of the emotion but I'm deciding what I'm going to do with it.

JOHN: Yeah, that awareness gives you that ability to make a choice about what you're going to do. This also actually ties in with the point I was sort of trying to find a point to make which is if you've got someone who maybe doesn't have the resilience that you were talking about, Britni, and you're trying to sort of help them through that process of getting from the 'no' to the 'yes', I think it's tempting to sort of rush in right at the time that the thing happens and be like, "No, no. Your life is great. Look at all the things you're grateful for. Let's get you as quickly as possible over to this positive outlook," and that can be really invalidating. And I think they call it silver lininging someone. Like, "Don't you silver line me," because you need to acknowledge what you're going through and whatever those feelings are before and go through them before you can get to that positive yes and state.

BRITNI: Yeah, definitely. And I think that whenever we do that for each other, it comes from a really nice place. You see that your friend or a loved one is suffering and you don't want them to be and you see all the great things and you just want them to see that, too. But yeah, definitely. It's very frustrating to be crying and have someone come over to you and be like, "What are you crying for? Everything's awesome."

JOHN: Yeah, that's when my oppositional defiance kicks in and I'm like, "No, fuck you, I'm sad."

BRITNI: We should make T-shirts that say 'Fuck you, I'm sad'.

SAM: [Inaudible] GreaterThanCode.com.

CORALINE: I'll do the stickers. Britni, I'm curious, what does that support network that you have around you look like? Are you relying on yourself for that resilience or some of it coming from the energy and support of people around you?

BRITNI: I've definitely developed it over time. I have a really good family. So, I guess I lucked out on that one. My parents are always letting me call and text them about whatever is going on, have always let me come back home when I needed to, if I've lost my job or whatever. And I know that a lot of people don't have that. So I think building up sort of your chosen family is also important too. You can feel really trapped in any kind of situation if you don't feel like you have a family to fall back on. And so just sort of building one up can be really important. And then for me, as a woman in software engineering really early on, all my communities in software engineering were sort of lady centric. I was with Rails Girls Atlanta and so I made a lot of friends there. And there's particularly a few friends that I have ongoing group chats with. Fortunately now, I work with a few of them. And so, having them to fall back on and just ask questions like, "Oh, this happened. Has that ever happened to you?" And kind of people to bounce my concerns off of and sort of to fall back on whenever things don't go right, sort of career wise. I have been through that experience in more similar way to the way I have has been really great. And then I also think it's important to build a spiritual community, whatever that looks like for you. For me, I'm an Orthodox Christian and so I go to a church that has a lot of people my age who I can sort of build that spiritual life with. But I know a lot of other folks find that in sort of Unitarian groups or even there's like a club here in Atlanta called Death Club, and people just go hang out and talk about death and I know other people enjoy that. So finding any kind of community like that, even if it's just like a book club, can be really great to just talk about things that are more deep. And you might talk about, if you were just like hanging out, talking about pizza which is also delicious and a spiritual experience sometimes.

CORALINE: Britni, how does that translate to your work environment because there are the major failures you're talking about or the things we perceive as major failures like losing your job or ending a relationship. But all these smaller failures that we face in our work life, what does that look like for you at MailChimp?

BRITNI: For me especially being newer to MailChimp and having worked at places that are much more dysfunctional in the past, I find myself surprised every day to see that my manager is very supportive whenever I come to him with issues that I'm having, like small things. Like one time, somebody submitted a PR for something that I was working on and it really frustrated me because I was like, "Oh, no. Was I working on the wrong thing? Should I be mad at that person?" And I just went to my manager and having a manager who listens to you and doesn't think of your small problems as small problems, really looks at them and says, "No, that's a problem and you're right to be upset right now." And 'what do you want me to do about it' can be really great. If you're someone who's managing people and you aren't listening to the problems they're bringing to you as though they are real problems, I don't know what you're doing because there's nothing more frustrating. I've definitely had managers at other jobs who would just like -- I would bring very big problems to them like people saying sexist stuff to me, people discounting my ideas and stuff. And I would tell them these huge things that were happening and they would just be like, "Oh, are you sure it was a problem? Are you sure he meant it that way?" And now having experienced good management, it's great having someone acknowledge my problems and then actively ask me what I would like him to do about it. Sometimes what I would like him to do about it is to just listen to me because I've already dealt with it. But sometimes what I would like him to do about it is, "Go, do your managerial thing about it." And so especially being willing to just be the person who acknowledges that something was a problem, whatever you want to be, like the problem solver.

CORALINE: What I heard is you need to have validation step in there and really the reassurance that you're being heard. That has to happen before any kind of 'I'm going to solve this problem for you' or 'we will work together to solve this problem' happens.

BRITNI: Yes, definitely. If you are experiencing problems at work and no one is acknowledging that those are problems, then it can make you feel very isolated.

JOHN: Apparently, acceptance is on my mind this morning because it seems to me that again, that's the first step between denial and validation.

BRITNI: Episode 130, the first step is acceptance. 

SAM: Done. I'm putting it in Slack. Speaking of acceptance, that's an important part of any conference selection committee process. A funny thing happened on the way to RailsConf. Britni submitted this amazing talk proposal for this thing called Lies the Developer Told Me. I saw it and I absolutely loved it and I rated it very highly. And then when I went to put together this track, I found that it didn't quite fit in the narrative that I had seen sort of emerge from it. I had a hard time letting go of it and I finally was like, "You know what? I just got to pick this other talk." And then unbeknownst to me, this was the 8th talk that you had submitted to a Ruby or Rails Conf and had not been accepted. And I felt really, really terrible about that. But you had some really great ideas in that proposal and you made some really good points. And I really wanted to hear more about them. So please, tell us some lies or rather tell us about Some Lies.

BRITNI: This actually really comes out well from that resiliency talk we're having because I think a lot of the lies we hear can really be things we have to be resilient against. And so, there's a lot of things that developers say to ourselves, to each other that we hear that people mean well when they say them sometimes. Sometimes, they don't mean well. Sometimes, they're just being ridiculous. But a lot of times, people have good reasons to say things that they think are true about what software development is like, who is a software developer, and the best way to write code. And a lot of times, those things can have unintended negative consequences for people around us. So when we're talking about lies, about who a developer is, one of the first ones that I ever heard was whenever I was first out of school, super bummed about not getting to be an officer in the army and just trying to figure out what I was good at, I started to notice that I was pretty good at computer things and trying to figure out what that meant as job prospects. I asked a guy that I knew who was working in the IT office at UGA and he told me, "Oh, you should do IT because girls can't code." I don't know why I listened to him. I guess because I was 22 and didn't know anything about what coding was anyway. But now looking back, I actually did because I was like the queen of geocities layouts and had been writing silly programs and basic whenever I was in elementary school. So, I don't know what he or I was thinking. But that was sort of the first lie that I heard about who is a developer. And then later on, you hear a lot of things whatever we're talking about diversity and inclusion, people are like, "Oh well, so-and-so is just our diversity hire," or whatever. As though they don't have every right to be there, as though they didn't go through the same selection process as everyone else and probably can code circles around whoever set it. And so, I think people will say a lot of, I call this category, the lies about who is a programmer. A lot of those are not well-intentioned. They're mostly to make whoever is saying it feel better about themselves. So, I think looking back at that guy at UGA, he probably failed at being a programmer and just wanted to make himself feel better about it by putting women down, I guess. And then people who want to say that other people are diversity hires or whatever, usually they feel insecure about their place at the table and may think that if other people will get to sit at the table, then we're going to figure out that they don't belong there and push them out.

The other category that I think people do a lot of is lies about what it's like to be a programmer. And so, people will say things like, "Oh, I could have a new job tomorrow. It's fine." There was a company that I was at that had rumblings of layoffs. And one of the guys on my team was trying to sort of make us feel better in a team meeting whenever we were talking about it. And he was like, "Oh, it's fine. The industry is hot. We could all have another job tomorrow." And little did he know that I had been actively interviewing for like six months at other companies and was not getting a new job tomorrow. And so, it made me feel really bad because I'm looking at these people who say that that can happen, so they must have done it before. And I'm sitting there, desperate to get out of this company even before they announced the layoffs. And so, it made me feel really bad. I mean, now from the other side, I have a lot more experience now. And so, I'll get all those recruiter emails. A lot of those recruiter emails are really annoying. They didn't look at your LinkedIn profile and they send you like 10 emails in a row that you didn't respond to and asked why you didn't respond. But whenever you complain about that around somebody who is more junior or like hasn't even got their first programming job, you're like, "Oh, I get all these recruiter emails." They hear that and go, "Why aren't recruiters emailing me? I am desperate for recruiters to email me." And if you can put yourself back in the shoes of someone who's just trying to break into the industry and think about how it will make you feel to hear somebody complain about recruiters throwing themselves at you, you can feel pretty trapped.

SAM: So it seems like a lot of those might be coming from a place of 'what's true for me must be true for everyone else'.

BRITNI: Definitely. There's a lot of things that we say that if you're really to consider that somebody else's life circumstances are different than ours, then those things are not facts. And so, I think what's really important is to be a little more detailed about what you mean and what you're trying to get across. So, if you're the person who's trying to make everyone feel better by saying that you could have another job tomorrow,  probably what you really mean is, "Oh, we're so lucky that we work in this very lucrative field and that the demand is pretty high." So, we could find something sooner than other people might in the company who are not in technology. And also, we're way more likely to be able to have a little bit of savings than someone who's going to get laid off who works in a lower paying part of the company.

CORALINE: I think some of that comes down to non-marginalized folks in tech. Assuming that their experiences are the default experiences and that they are the default kind of developer that really influences [inaudible] efforts too with what you're saying about that person's just diversity hire. It's like that person doesn't look like me. So they can't possibly be as successful or smart or as capable as I am because they don't match my picture of me as the default kind of software developer.

BRITNI: Definitely. There's also, and I guess this goes into the third category that I think of, is like what the rules are of writing code. There's a lot of lies that float around about what is and isn't the right way to write code. It makes me think of a talk that Sarah Mei gave, I want to say it was last year, could have been longer, about her experience coming up through the pivotal pair programming thing. And for me, my first job was one of those teams where you paired 100% of the time and every other developer on the team besides me was a white man with 10 years of programming experience and five years of knowledge of the exact code base that we were on. And so, this wasn't a pair programming experience where it was two equals trying to solve problems together. It was an experience where somebody with more experience and power was always basically telling me what I had to do. And so I never got a chance to think for myself or just get a second to try something that I know won't work just to see why it won't work. And those are the kind of experiences that I personally need in order to remember things better. I need to know why a triple equals won't work whenever a double equals will work in some certain situation. And the way that I've learned those things is through trial and error. I went to my manager at the time, told him, "Hey, I've been pair programming 100% for a year. I don't feel like I'm growing. I need to be able to just try things on my own sometimes and flail at problems," and also not have the emotional labor of trying to constantly figure out the way to express my opinion or try to get them to let me try what I wanted to try without hurting their ego or whatever. And every person on the team wasn't an ego but enough of them were that it stressed me out day in and day out. And my manager was just like, "No, the team gets to decide how they work and everyone else on the team says that they pair program 100% of the time. So, good luck." 

SAM: You are not part of this team?

BRITNI: Yeah, you are not part of the team. Exactly. Whenever I would ask them why do I have to pair all the time, they would say -- okay, if I'm really honest, it was like one person who was really a proponent of this and he was the loudest voice and most people just didn't want to have to deal with arguing with him. And we would end up doing what he wanted to do most of the time. And so, I think because of that, he would just say pair programming is the best practice. And here's one article that I read one time that says that it produces the best code. And also, I don't want to have to do code review. So based on just this one man strongly held opinions and everyone else's desire to not argue with him because it was admittedly very painful to argue with him, I had to sit there and not grow for two years. And I think that you're hurting people around you when you're not listening to the fact that your learned experiences are different than theirs. And also every person on the team who was a proponent of pair programming at that time had not pair programmed 100% as junior developers in their first job. They worked alone in a corner in a Java shop and flailed at problems for years and didn't see how that had made them more experienced and assumed that just because they liked pair programming better now and it may enable them to write better code now that it should mean that I, a person who was entering the field from a nontraditional background, who just wanted to flail at the code to learn, that I should have the same experience at pairing as they were having.

SAM: That's a really good observation because I feel like I also started as a software programmer. And when I did encounter pair programming and a lot of other parts of XP and especially test driven development, I was like, "This is great. This lets me go so much faster and make so many fewer mistakes than it did before. Why would I ever do [inaudible] the way again" But you're right, that going through those first few years of forming all those important structures in my brain that would allow me to get to that point was what allowed the new practices to make me go that much faster.

BRITNI: Yeah. And pairing can also be a really great way to share ideas, to get unstuck. Having someone there to tell me that I can't spell is really great. But whenever it's something that is forced on people as the best practice instead of used as a tool, like a lot of things in programming are, I think anytime anyone's reason for something is that it's the best practice or that their reason for not doing it is that it's an anti-pattern and the buck stops there, you're not learning. You're not open to doing the best work you could do because you're just stopping with some terminology. You hear people say, "Oh, we don't want to have fat controllers because that's an anti-pattern." It's probably true but that should not be what the code review says. The code review should say, "Hey, I've noticed you have a whole lot of methods in this controller that you could probably move out to two or three concerns and it would make it a lot cleaner and easier to reuse later." And people say things like, "TDD is a best practice." But hearing that, I'm going to be like, "OK, that sounds like it's going to make it really slow for me to write all this code, so I don't know what you're talking about." But if you go on to explain, "Hey, maybe you should try TDD because I've personally found that whenever I break the problem down into smaller pieces, it can kind of gamify the day and make it go by faster. Plus, when you get to the end and don't want to write a bunch of tests, you don't have to write a bunch of tests because you already wrote them." And whenever you just assume that the other person is smart and wants to hear your reasoning behind things instead of just telling them that something is or isn't the right thing to do because maybe sometimes TDD is not the best idea. Sometimes you just want to build a thing for fun or you're just spiking something and you want to see if it'll work and you have two hours to do it so you can prove to the team that it's worth working on it for three months. I think that as developers, we can sort of develop these opinions of what is or isn't the best thing just based on what we've worked on. I used to think, "Why wouldn't you do micro services? Why wouldn't we have like eight tiny apps?" But now, I work on a monolith and I'm like, "This is fine, too." And I think whenever you're more open to ideas like shoveling things as absolute truths to each other, then we all get better and we all get a chance to have the next big idea.

JOHN: Yeah. I feel like best practice and anti-pattern are conversation enders, like they're not invitations to discussion and context.

SAM: Yeah. And they throw away context. It's like somebody has discovered a heuristic where maybe 80% of the time, this is an anti-pattern. Or maybe even 90% of the time this is an anti-pattern. And if you throw that out one out of ten times, you're gonna be wrong. And if that thing is going to be exactly what you needed, then you're gonna say, "Well, nope because I have decided that that is not an option. I'm not even going to explore that." I feel like it also short circuits the learning process.

I really wish that I knew of a way to teach people that didn't involve pain or a way to learn that didn't involve pain but pain can be a great teacher. When you encounter that same stimulus again and you're like, "Wait a minute, something's going to happen here." It gets you to pay attention and be like, "Oh OK, now I need to think through this very carefully." Also, that situation you're describing in those pairing interactions reminds me of what Betsy Haibel calls nonconsensual teaching, which is a phrase I just love.

BRITNI: That's like the next level of unsolicited advice.

SAM: Yeah. 

BRITNI: It might be good. But nobody wants it.

JOHN: Right.

SAM: Yeah. That goes back to what you were saying about pair programming in the situation that you were in. I think people don't realize that there are kinds of pair programming and that there are different kinds of sessions that you can have. And based on the people who are there and the task that they're there to solve, you can employ different strategies to achieve different outcomes. Do you want to get the feature done? Do you want to bring somebody up to speed fast? Do you want to explore a new problem? These are all different things.

BRITNI: Definitely. There was even a time that I thought was pretty cool. We were on that same team trying to learn Elixir to see if we wanted to use it for some project. And so we mob programmed as a team on it because only one or two people were really familiar with Elixir. And so, those two people weren't allowed to drive. So everybody else got up there, took turns driving. And together, eventually, we started to figure out what was going on. And as a team, we all got more familiar with it. I think using something like that as a tool can be really great. But then later on, the team decided, "What if we mob program on everything?" And it was my real nightmare. They were like, "It worked really well for this, so it must work well for everything."

SAM: It has a golden hammer, let me show you it. 

JOHN: Well, if two Tylenol is good; 10 Tylenol is better. 

CORALINE: Sam, what you are saying about contexts and throwing away contexts is really important. I think what you're describing, Britni, is a form of pattern matching. Someone, in this case, more senior than you had observed that a particular practice worked well for them. That became their knee jerk reaction, right? That this is a solution to every problem. And so, what Sam was saying about ignoring that context and not acknowledging the fact that you could be wrong, I think we're kind of wired for pattern matching but we have to not let our subconscious reaction guide our actions all the time. We need to be rational. And when you think about consequences, you just think about the people involved and what sort of social dynamics are there. And as we've said, the kind of problem you're trying to solve and focusing on that, as opposed to, "Oh, I've got this."

BRITNI: I think sometimes, too, we don't realize that the best practice is the one that the most people can't just agree to do. Yeah, Elixir is way faster than XYZ language but it's not way faster if nobody knows how to write it on the team. The code will run a little fast but at what cost? And then it could even be little things like I hate trailing commas but the internal style guide at MailChimp says that we use them so that we can make the git diff look better. And if everyone's agreeing to do that, I'm happy to do it. Just tell me. Tell me that that's what we have to do because it's in the style guide and everyone's agreed to do it. And once you have a document that is 'these are the things we've agreed on and this is the process for changing it', then it's OK to reference the document as long as people agree that there is a way to amend it. It's not like set in stone forever. And as long as we all agree that the thing we're trying to do is just figure out how to work together, I don't think that having a document that says this is how we do things is the same as saying something is the best thing to do. I think it's just saying this is what we got to do because we all have to work together.

SAM: One thing you said earlier, Britni, that we sort of skipped past that I wanted to come back to was that there is this category of lies about who is and isn't a programmer. I was thinking about this actually the other day looking forward to this call and remembering that way back in the day, a lot of how I learned about the culture of programming was by reading Joel on Software, which I remember really liking at the time. And if I went back, I probably would still find some nuggets that I agreed with. But one of the things that I sort of absorbed and internalized without really examining was this thing he said about how he feels like there's this part of the brain that understands pointers, was what he was talking about. And some people have that part of the brain and other people don't. And he formed this observation watching people like go through a university CS class and then hit pointer in direction and then bounce off of it. For a long time, I also believed that there was just a certain kind of brain that could get programming and there was a certain other kind of brain that could not. And I have come to understand how wrong that is and especially how that particular criterion is wrong. But I feel like that kind of thing is a pretty common lie in programming and I wanted to at least name that.

BRITNI: Definitely.

SAM: Are other ones that you've heard in that category? 

BRITNI: I had like a whole list but I think that's a good one. The one where certain brains are more up to it. And then I think that idea that certain brains are better for programming than others also feeds into this other lie about programming is easy or programming is hard. Either one of those. Whereas if you say, "You could do programming. It's easy." And then someone tackles it, trying to learn it and it's hard, then they think, "Oh well, I'm not equipped to do this." Whereas maybe they are, they just have to get past that first wall. Or if you tell someone programming is really hard, then they tackle it and they find it easy, then they go, "Oh, what I'm doing must not be programming. This is probably just like some low level thing."

SAM: Oh, yeah. I hadn't really thought about that flipside but you're truly right.

BRITNI: Yeah. And I think for me, it goes back to whenever I was making my little geocities pages and putting silly marquee tags on things. I mean, that's programming. It's not like the most high tech but neither was anything in 1994. It's about as good as anything else you're going to see in mid to late 90's websites. I could have made the Space Jam website, it looks pretty great. So thinking back on that, "It wasn't hard. I just had to Google some stuff," or whatever the equivalent to Google was at the time. AltaVista? And I thought, "That's not programming." But now, I'm here and I know that the frontend is really hard and I don't want to touch it. I go, "Well, that's programming."

There was a group of Girl Scouts at a hackathon I went to who were using App Inventor and Scratch to build some stuff. And they built away cooler thing than I built at that hackathon. I would say that's a group of 8-year old programmers.

CORALINE: Another situation like that that comes up is interpersonal skills. We allow people to hide behind technical merit and simply say, "Oh, I'm not good with people." Or, "I'm not good with empathy," and assume that, "My brain is not cut out for that kind of activity. I'm not going to focus on it. I'm not going to develop it. I'm going to discount it. I'm going to say it's not important."

BRITNI: Oh, definitely. And historically, for some reason, that's the thing we've let people get away with in programming. I mean, it's responsible for that shift in the number of women programmers from being most of programmers to being very few programmers. And I think we're finally at the point where we're bouncing back or accepting that talking to people is part of the job. But yeah, definitely early on, there was a lot of the idea that a bit of my theory on it is that there were the people who were antisocial and good enough at code but not good at explaining it. And so, they would explain to their managers kind of in very complicated terms and the manager would go, "That sounds really difficult. You must be a genius. Promote now." Whereas people who are good at explaining it would explain it probably something equally difficult in a way that the manager could understand it and go, "Oh, you must not be working on stuff that's as difficult as that guy. So go over there and keep doing it," I guess. It's interesting the way that we perceive how difficult someone's work is based on how well they explain it.

SAM: This is neither here nor there. But you've just reminded me of a joke that somebody told me a long time ago about the difference between dogs and cats. Dogs look at humans and go, "Wow! You bring me food. You must be a god." And cats go, "Wow! You bring me food. I must be a god." 

BRITNI: I think that applies. I think that's how that works in programming.

JOHN: Okay. Tie it in. 

BRITNI: So, I'm of the opinion: don't tell anyone's employer that programmers definitely get paid way too much compared to other people in the company who I think have harder jobs. I would not want to work in support. That sounds like a very hard job. So yeah, programmers see how high their salary is and go, "Oh, I must be a god."

JOHN: Yeah. Try teaching or social work sometime, really.

BRITNI: Yeah. Teaching sounds terrible. Teaching sounds so hard because everyone's been graduating recently and I see all of my teacher friends on the Internet who are writing these senior letters. They write a letter to every senior at their school. That's like 150 kids. How many hours do they spend on teaching things? They go to work for like 7 to 8 hours and then they come home and spend 3 to 4 hours making the lesson plans. And then they have to write letters because they're nice people. No, that's a very complicated job.

JOHN: I wonder if there's another lie in there. Maybe this is just a lie that we tell ourselves and I don't know if anybody tells it to other people. But one of the lies that I have told myself certainly is, "I'm a programmer. I get paid to turn money into code. Therefore, if I am not turning money into code at this moment, I am not doing my job."

BRITNI: Definitely. The idea that the glue work you do isn't as important as writing lines of code is definitely a huge lie that we get told all the time. Whether we're telling ourselves that or whether we're telling it to other people, you can't really measure somebody's output in lines of code because maybe you did something this week that allowed eight other developers to not have to get away from their keyboard. And how do you quantify that? Your name isn't in all those PRs but you were the one who got the product people off their back or who went and fixed whatever thing was going wrong in pride, or you went to a conference and brought back new information that everyone else is going to use. So, the idea that if you're not like [inaudible] at a keyboard all day and turning out a PR every single day, it's kind of asinine. I get it. You want to feel like you're producing something but I think that there's better ways to measure it than some number. Especially, it's really language dependent, right? 

I gave this talk at WeRockIT Conference last Friday. I kind of went around the room and let other people tell me lies they've heard. And someone told me that one of their professors told them that you're not a developer until you've written 10,000 lines of code. And I guarantee you I've not written 10,000 lines of code. There is no way. I maybe have spun up enough Rails new to have turned out that many lines. But me personally, I'm not writing Fortran. So, nothing takes that many lines to really get done.

CORALINE: I heard a horror story about a company that had two languages. They had Java developers and they had Ruby on Rails developers. And they measured people's output in lines of code. Java, being a very verbose language, the Java developers would get promotions and the Ruby on Rails developers would not because they're like, "Your output is terrible." And they made assumptions about the language, like Ruby you must be really hard or really way too simple if you're not writing 500 lines of code in a single PR. 

JOHN: But look at all the things I'm not doing.

BRITNI: But also, you end up with some really messy code whenever that's your metric. I could make a really long Ruby method but who would want to read that whenever I could just do append three dots to the end of it and everyone would know what it does. Whenever you come up with really asinine metrics, people find a way to gain that for their own benefit. And can you really fault them for doing it whenever that's the standard you've given them?

JOHN: I could get it from you.

BRITNI: Like you want me to write a ton of code? I'll do it. This is gonna be messy. Here we go. I think it's interesting, too. People say things like, "Once you have X number of years of experience, then people will be throwing jobs at you and you'll know all this stuff," and blah...blah...blah. "You'll get promoted instantly." But I think what you're not really telling people is like, "This is how the system is. What you really need to learn in your programming career is yes, you need to learn the tools to be a good programmer. The thing you really need to learn if you care about your career and about your friends also having good careers, is how do you take your lived experience and make that operate within the parameters of whatever nonsense system has been built up before you got there." It's sort of like, "Capitalism sucks," but also, that's what we have now. Also, this is how it is now and this is how I'm going to try to operate within this but still also help other people lift themselves up in it as well. People ask me, "Do you love programming?" And I'm like, "Yeah, it's fine. It's good." I could be doing a lot worse things for work that would pay me a lot less. But the thing that I love about programming is that (A) I get to say I built something at the end of the day, and (B) it's this way that I've seen so many people from so many backgrounds elevate themselves out of situations that they might not have been able to get out of any other way. Single moms who had babies in high school are now making six figures and putting their kids through really nice colleges. And seeing people from just underprivileged high schools that no tax dollars go to, teach themselves to code on the side or go study at Georgia State and then become tech leads at big companies. It's really great seeing that. It's a field where you can elevate yourself but the idea that you have to love the code or else you're not a real programmer is one of the biggest lies, I think.

SAM: Well, it's that time again where we reflect on what we've talked about. If there's anything that we've learned, if there's anything that sticks with us, if there's anything we want to carry forward as we go through better days. And for me, I feel like the conversation about lies is really important. And I'm really glad that our listeners are going to hear it. What I think is going to stick with me personally from today is the conversation right at the top about resilience and about not wallowing. Because I was like, "Wait a minute. You can do things that aren't just wallowing?" And thank you for reminding me, Coraline, I know it was just last week that you talked about naming depression and naming emotions as a way of turning them into something that you're experiencing and not something that you are. Because I heard that last week and it was really important. And then just recently, I forgot it again. And so, I appreciate being reminded of that. I'm also reminded that, Britni, you said that part of the key to not wallowing was to have other people around you and to have communities of peers and support. And that is also something that I've been working on a lot and that helps me a lot just in this call. So, thank you again.

CORALINE: One of the things that we didn't quite talk about but the conversation that got me thinking about is how we respond to failures or apparent failures and the impact that that can have on other people if we show that resilience, if we lean on our communities and show that these communities are valuable and they're helpful to me and we bounce back in a very public way. That can be really inspiring to other people. I think in a way that automatic success is not inspiring to people. You talked about how programming can be hard or it can be easy and when we make a blanket statement about it one way or the other, how we're excluding people. I think if we also say, "I'm very successful and it's because of X, Y, and Z," people who are doing XYZ and who are not very successful are likely to blame themselves or to think, "I'm not cut out for this." So, I think being public about the things we've tried and failed at can be just as inspiring to people as the things that we've tried and have been very successful at.

SAM: Ok, bonus reflection. You're talking about having a certain number of years of experience and then just being an expert programmer who is automatically qualified for all jobs. I almost threw this in then but I'll throw it in now. I have been programming for 21 years and I am not qualified for the vast majority of full stack Rails jobs that are out there. That's just where I'm at. And that's OK.

BRITNI: I think what I'm going to take away the most is earlier in the conversation around resilience. I hadn't quite named acceptance as one of the steps I think in my head. I knew that I was doing that but I hadn't quite put my thumb on that being sort of the gateway between the 'No, but...' and the 'Yes, and...'. And I think going forward, I'm going to be able to think around that a bit more. And then, to piggyback on the last two reflections, I think I'm going to be a little more intentional about broadcasting my failures as well as my successes because I think the more people are sharing the times that they failed, the more people can stop feeling so alone about those things and the more they see that they too can get past those. And like [inaudible] saying sort of move forward and show the real path to success is sometimes rockier than we think.

CORALINE: Britni, thank you so much for coming on the show today and I wish you the best of luck in giving this talk. I'm sorry you couldn't give it at RailsConf but I hope you will submit it to other places because I think you have a lot of really great ideas and you bring a lot of really valuable insight into what it means to be a developer and also what it means to be a human being. So, thank you so much.