PREROLL: Explore DDD is offering hands-on and highly interactive workshops this year. Workshops will take place over the course of the last two weeks in October and the first three weeks in November. 

Instructors include industry leaders such as Scott Wlaschin, Kacper Gunia, Marijn Huizendveld, Jessica Kerr, Kent Beck, Alberto Brandolini, and Paul Rayner. 

Why should you attend? No travel! No flight delays, passport control, or security checks. Worried about losing your luggage? Forget about it! 

Challenge your thinking in an open, sharing, and collaborative environment while accessing the workshops from the comfort of your own home or office. Take breaks as needed. These are strange times we are living in.

Use the time you would be traveling to report to colleagues on key lessons and takeaways. Help them to expand the skills you’ve learned from these innovative, remote sessions, and then incorporate them into your organization.

Talk to your boss and tell them how you would benefit from attending online workshops from Explore DDD. Relay the cost savings you will benefit from by not traveling this year. Visit  http://exploreddd.com/workshops/ and register today. Use the Code EDDDGTC to get 10% off the price of any of the workshop tickets!

DAMIEN: Welcome to Greater Than Code, Episode 207. I’m Damien Burke and I’m here with Amy Newell.

AMY: And I’m here with Jessica Kerr.

JESSICA: Good morning! And I’m right here with Avdi Grimm.

AVDI: Hello! And I am here with our guest today, my favorite current aficionado, Chelsea Troy.

CHELSEA: Hey! How ya’ll doing?

AVDI: Chelsea writes code for mobile, the web, and machine learning models. She consulted with Pivotal Labs before launching her own firm to focus on clients who are saving the planet, advancing basic scientific research, or helping underserved communities. 

Chelsea live streams her programming work on NASA-funded mobile and server projects, and she teaches Mobile Software Development at the University of Chicago. Off the computer, you'll find Chelsea with a barbell or riding her e-bike. Gigi?

CHELSEA: Gigi. 

AVDI: Gigi.

CHELSEA: That’s right.

AVDI: Above and beyond all that, Chelsea is also one of my longtime favorite writers on all things software especially a lot of the social factors and inhuman factors around software development. So I’m very, very happy to have you on the show.

JESSICA: But also super technical stuff: data science, automation. What did you implement? You implemented Raft] the other day. Well, by the other day, I mean – [overtalk]

CHELSEA: Oh yeah. there’s like this long, long say, 13, I think it was 14 posts. It was about the Raft distributed in Python.

AVDI: Yeah, I should be clear about that. It's just that some of my favorite posts are like the team dynamics ones, but you have an incredible technical output.

CHELSEA: Well, we wish the social stuff was as easy as Raft. Easy, oh man. Raft, the understandable distributed consensus algorithm which makes you wonder what all the others are like.

AVDI: Is that anything like the gentle introduction to Haskell?

CHELSEA: Probably. Probably approximately the same. There's just certain situations where it's going to be a roller coaster one way or the other and I think that's probably one of them.

AVDI: So Chelsea, I can probably think of at least like half a dozen superpowers you have off the top of my head just from past conversations. But what would you say is your superpower?

CHELSEA: I would say, I don't know about superpower, but the thing that I've been working on a lot lately and seeing a lot of progress with has been my software detective work. So a lot of the work that I do lately has been with a grant-funded organizations and the thing about a grant-funded organization is it sometimes there's funding for the project and sometimes there's not funding for the project, which means that it's not uncommon—and I think this is the case even outside of grant-funded organizations. 

It's not uncommon for there to be context loss on the project often in those particular cases, because it was one developer working on it and that developer is no longer available and so, the next developer effectively needs to national treasure their way to figuring out how the software works and how to use it before they're going to be able to update it, maintain it, deploy it, any of those types of things and I think that that is perhaps the most extreme case of context loss when there was one person who ever knew and that person is gone. But I think that context loss happens at any organization, maybe to lesser degrees than that, where there was a particular thing in the software, it works this way. Nobody currently on the project is really sure why and a lot of times that context loss engenders some about [05:31] touching various parts of the system. 

And so, the skill that I've been working on the most lately is a skill that I've come to sort of colloquially call forensic software analysis because it makes me feel like I'm on CSI. But I go in there and I've gotten a lot better at being able to figure out what's going on, how to figure out what's going on to get into an investigative mode that helps me determine what's working and I have found that those skills also transferred to debugging on almost any stack. They tend to be language agnostic skills that I can use when something's wrong in the software to figure out how to narrow down the cause and once I have the cause narrowed down, once I have a tight feedback loop around, figuring out what's wrong, then I can try a whole lot more stuff in much more rapid succession. Because I went slower in the beginning, I can end up finding and solving the problem faster in the end.

JESSICA: Where can I buy your book? 

CHELSEA: Oh my gosh, I wish I had a book. I don't have a book yet. One of these days, one of these days. If there's a publisher listening who wants to toss me an advance, I'm totally interested so let me know.

But it's been a bit of an interesting kind of journey because I think the vast majority – this is what I think this is the opinion that I'll one day get Hilary for, maybe not, is that a lot of software tutorials, a lot of the education around software, and a lot of the conversations around software assume that the software works and assume that we know how the software works. 

So a lot of tutorials—and I've done a lot of tutorials myself, I'm a teacher—and the truth is you don't go in there, I don't go in there and like on the first shot, do a tutorial that works almost ever. Usually, if I do a tutorial and it's a smooth tutorial, I have practiced that at least once before. When I'm doing live coding, if something works seamlessly, I have definitely practiced that like 19 times minimum. That's most of the demonstrations of writing code that we see, but that's not the way that writing code works. In reality, in my experience, we spend so much of our time at the edge of what we know, because if it had already been done exactly the way we need to do it before, nobody would pay us a lawyer's rate to do it this way; they’d just use it the way that it had been done before.

So there's this whole skillset of operating on the edge of our knowledge, where we don't know what's going on that I think we tend to kind of ignore, to some degree and we don't necessarily talk about it as much, such that then when we spend time on it, while we're writing code, we feel like we're doing a bad job. We feel like we're not doing what we're supposed to be doing because what we're supposed to be doing is cranking features at top speed. 

In my experience, once you're no longer in a Greenfield application where you're the only one that wrote it, the amount of time that you spend doing that just goes way, way down and there's something to be said for acknowledging I have to spend some period of time in investigative mode on this code. Once that's acknowledged, we can work on improving at that mode and once we're improving at that mode, at least in my experience, my ability to resolve real problems in code basis has become so much better and my confidence in my ability to walk in and help somebody with a longstanding bug is so much higher. 

JESSICA: Can we do a quick round of the panelists of what percentage of time y’all expect to spend in investigative mode when coding in a real production system?

DAMIEN: I mean, this is such an amazing idea. In our education systems, we assume that the code is working and that we know how it works. In real life, of course, neither of those things are true because of those things were true, we wouldn't have work to do. Boom!

JESSICA: I love it.

DAMIEN: I think that it's hard to say that I don't spend all my time in that mode.

AMY: Nice. Possibly unique among the panelists; I don't presently write any code for my work. I'm 100% a manager or business cat and I obviously think about this problem a lot. Most of the people reporting to me are working in an old code base now, like it's over a decade old. So they themselves are spending a lot of time in investigative mode. It's not so different from the work that I do, investigating sort of longstanding bugs in sort of human interaction either. If everybody worked together well all the time, I would not have a job.

Additionally, the thing that you said Damian about – well, I think that both of you said, you talk to software developers and most of us will admit quietly like, “Oh yeah, everything is trash. Burn it to the ground. It's amazing any of it works. It's held together with duct tape and bailing wire.”

AVDI: Amy, what you just reminded me. I watched a talk recently by INR host where he says, “Well, what we have is not technical debt, what we have is organization debt.”

AMY: Yeah, absolutely.

DAMIEN: So given that everything that we do is broken and we don't know how it works and now that we can recognize that and accept it. Chelsea, what do we do next?

[laughter]

JESSICA: Awesome.

CHELSEA: It's a good question. So my thought, the way that I characterize it is like this, I think basically we've established that we have two modes. We have sort of this build mode, this productivity mode and then we also have this investigative mode and the goals of those two modes are different. The goal of the first one is to crank some features, to get something done, to make something work, to make something happen. Investigative mode, the product of the investigative mode is not working code, it is instead a tighter feedback loop. The product of investigative mode is a series of places where you know that the problem isn't happening and a smaller window where you see that the problem is happening. 

I find that when I am able to acknowledge that and switch from trying to get it to work into trying to figure out where – I don't need to know why it's not working, I don't need to know how it's not working; I just need to know where it's not working and then I can figure out the rest from there and I find that that helps to provide a sense of progress in debugging, even if we haven't necessarily found it yet.

I like to draw an analogy here to a detective. I'm sure we've all seen crime shows. My latest favorite is Lucifer, that's neither true crime nor – just don't watch anything Lucifer for accuracy anything. Nothing in that show is the way it works in real life. But the idea of a TV show is that the premise itself is going to sound ridiculous. The devil comes up from hell to live in Los Angeles and solves crimes on a voluntary basis and the rest of it is about as realistic as the premise makes it sound.

But the point is, we watch these crime shows and what we're interested in is the process of solving the crime. We think of it as progress when we see interviews with witnesses and clues and thinking and that kind of stuff. But then when we're writing code, we think all of that as like, trash work that doesn't really count as working and the only thing that's going to count is when we find the fix. 

But when I'm thinking about myself as being in investigative mode, I count that investigation as progress that I've made. I know that I have this issue where I've got this React Native app where people can classify images from the surface of Mars and they can draw boxes around stuff and delete those boxes on iOS and they can draw boxes on Android, but they can't delete the boxes. Why does it work on one platform and not on another? As you may imagine, this is an actual thing that I'm dealing with right now. 

So I go into the code and I start figuring out where the problem could be. All right, the outputs at this point on Android and iOS are the same. The outlets at this point on Android and iOS are the same and I move further down. All right, the output on iOS now is this index of zero, but on Android, for some reason, this is undefined. Why is it specifically on Android? 

JESSICA: And to get to that point, I'm guessing you had to set up a debugging environment in both iOS and Android and how many days did that take? 

CHELSEA: So it helps that I have a little bit of familiarity with this environment at this point, but yes, it is a little bit of a thing.

So I was joking about this the other day, that Java reminds me a little bit of a puppy. It has very specific uses in our life. It's relatively easy to train. All you need is like a soft rope and maybe some treats. This is a React Native app. JavaScript is a little bit more like a velociraptor. [laughter] It's so versatile when you need it to be able to operate in any environment, a velociraptor is who you're going to. 

But the thing is, it's going to take a lot more than a nylon rope and some treats to discipline a velociraptor and, in that spirit, this React Native app that I'm working on. You can put console statements if you want to, but unless you put them in very specific places in a React Native app, they just will not show up. The console statements will not print, but if you throw exceptions, that will show up regardless of what thread you're on, regardless of it's async, whatever happens and so, that's my velociraptor chain is that I know if I just, when we get to this, method's throw oh, you have reached this method exception. 

AMY: Can I go back and pull a thread here. Chelsea, when you were talking about the difference between kind of writing code you think features fast versus investigation and how many of the engineers will consider the investigation piece somehow not real work, which I see a lot, not just around investigation, but in engineering, we can have this very narrow definition of what our real work is. 

I want to link this to what I think you were hoping to talk about on this podcast and that I did my homework over by reading your posts about it.

CHELSEA: Yeah, that’s right.

AMY: Which is that what you're talking about in those posts in terms of thinking broadly about engineer's work as being considering the sort of the consequences broadly of their actions in the workplace and kind of working towards a better world.

CHELSEA: Yeah.

AMY: That's not too far of a thread pulled there.

CHELSEA: No, no. Yeah. I think this makes sense. So this is the way that I've been thinking about this lately and like I said, I've been focused kind of on this detective work because I'm interested in figuring out how to build more kind of robust, resilient systems. That's where all of the work has been lately with the distributed consensus algorithm and working on debugging and learning about software risk analysis, different ways you can test systems, that kind of thing. 

But the impetus for all of that work has been to think more systematically about the work I do. Because when you start out as a software engineer, I think you start out by thinking on the level of this method, this class, maybe this interaction between these classes; that's sort of the scope that you're thinking about and as you rise in seniority, you're thinking about maybe more whole modules within an application and then the whole application itself. Then as you rise through the senior rep to the staff level, you're thinking about how this application is going to interact with other applications in our system and once you get to principal, you're thinking about how all of the systems at the organization work together to accomplish the goals of the organization. That's your responsibility as the principal is to be thinking in that larger sense to understand the context. 

I find it really interesting that we understand how to think at these broader and broader levels of abstraction as we rise in seniority. But there is some, I don't know if it's a stigma so much as a more indifference in the software engineering community, to thinking at the broadest level. To me, which is the impact that the software that we're putting into the world is going to have on the people who interact with it, the people that's supposed to benefit, the people that it affects, and to what degree we can impact the system that produces that software and the system that it ends up impacting. 

So when I roll onto a project, I'm thinking about the technical—how this is going to play into things. But something that I think it's also incumbent upon us is this software that we're writing, what social systems have contributed to the need for this software are those social systems that I'm comfortable playing into that that my values align with? When we put this software into the world, it's going to have an impact back on the system that influenced how it was built. Is that impact something that I am prepared to sign my name on and say, “Yes, I wrote code that directly impacted the way that this now works for a whole bunch of people.”

So that's something that I think a lot about in my work and when I'm taking clients, it's something that I think a lot about, too is like, is the impact that my work is going to have and the impact that I want my work to have and when I look back, how do I want to have used my influence as somebody with the technical privilege that I have and as somebody with the rhetorical abuzz that I have. That’s some degree of influence, I suppose and I want to think about how I've used that. I think it's valuable for engineers to do in general, anybody in technology, anybody in general, but in my specific – I speak to engineers because I'm an engineer and that's what I know.

DAMIEN: So as you move up these layers of abstraction, things get a lot more difficult, things get fuzzier and when you get to the level of your customers and the social structure that created the product and the company and the social structure that's created by it, there are no obvious answers. I don't know about anybody else; I got into this business for obvious answers. So how does a person like that, like I am, well, how do engineers adjust to that sort of problem?

CHELSEA: It's tough and to some degree, it involves in order to figure out how to do this, we're dealing with a system with so much ambiguity, like you're saying. One of the things that we do as software engineers is attempt to impose a system on ambiguity and find a model that is perhaps not 100% right, but it's somehow useful for helping us deal with that ambiguity—and that's effectively what I've tried to do in this regard as well. 

So when I'm thinking about the different ways that I interact with software, there are a couple of different ways that I do it. I write software, that's one thing that I do. I write about software, which includes, to some degree, an influence on other people who write software. And I also consume software. I purchase software products. I purchase things through software products; my money is going somewhere. Once again, because I write and to some degree, I guess speak the decisions that I make about what I purchase also kind of spread to other people. 

For example, there'll probably be at least one person who checks out the TV show, Lucifer, as a result of this episode and to that person, I want to say to you directly, I did not endorse that show! I just mentioned it. I did not endorse it. 

[laughter]

The point is that the influence is there and so, I think about that when I'm thinking about companies and how I want to act in accordance with my values. I tend to leave aside the question of what people's values are. Reason being, that our values change over time. I'm always going to have more to learn, I'm always going to have more to think about, and I reserve the right to be able to change my mind about things as I learn more. 

So regardless of what somebody's values are, I think it's helpful to think about how to use these different types of influence that we have in accordance with those values and I tend to divide it into four categories. So the four kinds of influence that I think about myself having on tech are first of all, my patronage, where my money goes, and then second, my patronage advocacy. 

So where I convince other people to put their money; if I talk about a product that I really like, maybe somebody buys it. So in some respects, my patronage advocacy is more valuable really to my patronage because I only have so much money to give. But if I convince other people, then that is a multiplicity of the amount that I could give and maybe even more influential than patronage advocacy is where I put my talent, who I work for. 

So I distinguish talent from labor, not based on one being more rarefied and requiring more training and being more valuable, but based primarily on the margins. So labor, I tend to think of as something that's relatively low margin for the company. For example, when somebody drives for Lyft, they make about 70%, let's say of the amount of money that the customer pays. So that's relatively low margin for Lyft. 

Meanwhile, a software engineer for Lyft—let's say, that they're part of a team of ten that chips a feature that increases Lyft’s revenue by a half a percent over the course of a year. At that point, the amount of value that each of those engineers has brought to Lyft, even counting the fact that they're only making the 30% cut, is easily double what any one of them is making in a year. 

The margin is much, much higher for the company on that engineering work, which is how I distinguish the talent from the labor because one of them is an essential service, the business doesn't exist without. The other one is also essential, but not in the way that the business wouldn't exist without it. Rather, in the way that the margins for the business on that work are so high that any individual person who does that work automatically has more influenced by leaving and therefore, has more leeway in a lot of cases to say things about how the work is done and what work is done. 

So the final kind of influence, which I think is more powerful than providing my talent is my talent advocacy—and this is more powerful for the same reason that patronage advocacy is, is more influential than patronage. If I get three people to buy something, that's three times as much as the money that I spent. If I get three people to join an organization that I'm working for, then that's three times the talent that I could provide. Presumably usually more than three times to talent, because a lot of my friends are a lot more talented than I am, of course. But because of that multiplicative effect, my talent advocacy, who I recommend somebody work for, is like the most powerful thing that I can use as a software engineer and because of those things going in increasing order of impact, I am increasingly careful about how I use each of them.

So in some cases, and we know that capitalism is an extremely powerful system that we're all kind of like stuck in for the moment, right? There are certain cases where I need something and I have to give money to an organization whose practices, I don't completely agree with. 

Avdi, you have a great example of this with like cell phone companies. Cell phone companies, each have a series of customers. Most of the customer lists for any given cell phone company, or other service provider, include organizations that I would rather not have service. But at some point, I have to call my mom, right? So at some point, my patronage has to go somewhere where I don't necessarily 100% agree with everything that's happening at the organization. That's a decision that I have to make, but I can make it with the understanding that I'm more careful about each of these different levels of influence. 

Would I specifically recommend a particular service to people that's going to require a more rigorous understanding of their values on my part? If I'm going to go and work somewhere, that's going to be a big jump in the amount of rigor that I'm applying to my understanding of their values and determining whether their values align with mine. And even more than that, who I'm recommending somebody go work for and refer people into is going to be an even more rigorous determination on to what degree can I help this organization from an ethically stable standpoint?

AMY: This notion of the most powerful thing that you can be doing in your tech life is what companies are you advocating that other people work for, it’s really powerful to me. That's something as someone who does a lot of hiring and also advises a lot of other people about where they might fit in, also feels like very high leverage to me. “I'm going to send you here and I'm going to scare you away from there either because there are things, I know about that culture that are non-ideal or because of the work that that company is producing.”

DAMIEN: So here's my question. So you've built out this amazing framework from patronage to advocacy, to labor, to talent, to talent advocacy, which is a great way of saying exactly how much leverage impact you can have. This is going to be a difficult question because you mentioned you didn't want to talk about specific values, but making the connection between values and the work you do as an engineer, or the people you appoint people to work for. How do you draw that connection?

CHELSEA: Yeah, that's a good question. So I think that one thing that has helped me a lot in thinking about this is understanding the role that privilege plays in the degree to which we can comply or not comply with the system that we are steeped in. 

So I will say one peculiarity about this entire system with the patronage and the talent advocacy and all this is that the whole system assumes market capitalism. Like, let me just say that podcast listeners, none of this works outside market capitalism the same way that it does in market capitalism and the reason it's valuable for us as engineers—well, I think all of us are States-based engineers here on the podcast right now, anyway—is that that's very much like a [inaudible] the system that we are working with here in the States specifically and I think to some degree, with tech globally as well.

The thing about a system like that is that there are situations in which we have choices, and there are situations in which we don't have choices, and there are situations in which engineers have more choices than people in like a profession where there's not the same ratio of people who do the job to people, to openings for the job. Or there's not the same margin that a company is making off of each and every one of us and acknowledging that helps me kind of think about how I can do this work because I can focus on using my leverage in the places where I have the highest leverage and prioritizing that essentially playing to my strengths. 

I can give some examples of this, with regard to work specifically. The thing about large tech companies, a lot of them are involved in practices that are hard to agree with, but there's a question of the total impact that we can have maybe a working at one of those places or purchasing from one of those places. 

So a good example is that like, I don't want to name any names on the, but there are certain types of software that are just considered the standard that we use for collaboration because it's free and everybody can kind of work in it and there's a tradeoff to be thought about with regard to like, how hard is it going to be for me to switch to a different system? How hard is it going to be for me to move literally all 190 activists that we're working with onto a different system versus the one that they know, and they understand? In those kinds of situations, there is a calculation to be made about the amount of impact that we can have, but I think that the position that we're in affects the amount of impact that we can have. 

So I'll give another example. I was talking to a team at a company that has a contract with ICE. I was talking to this team a while back about a product that they have that has maybe nothing to do with ICE itself. But there's a question of like, if you're working on this product, does that therefore, free up time and attention for folks to think about something that helps a more morally reprehensible organization. 

That's one of the arguments that I think software companies have to think about is like when we sell to an organization that is keeping kids in cages on the border or whatever, even if the software that they're using isn't like, whatever, keepkidsincages.li or something like that. Maybe if it's not directly – we're not sure the degree to which it is directly related to these things that we don't agree with. What can we do? I think that that's absolutely something that tech companies need to think about. Tech companies are in a powerful position to think about that. Individuals working at those tech companies are not always in as powerful a position. 

There are things of course, that engineers can do in those situations. They can leave. Some engineers have the power and the privilege to be able to leave in those situations and know that they're going to be able to land at another company. That's not necessarily the case for everyone, but that doesn't mean that those people necessarily agree with the practices of that company. And so, this is something that I've been thinking a lot about lately is, what is incumbent on those with a privilege in a situation where they might be talking to somebody without. 

Something that I've been thinking about a lot lately is like, to what degree, rather than judging the decision that another engineer has made about how to allocate their patronage of their advocacy or their talent or their talent advocacy? Like, rather than judge the way other people are allocating their influence in those four areas, what influence do I have that I could help them in areas where they can't necessarily do that. 

So back to the example, I'm talking to this company, they make them this product that I use in my teaching practice, because it's a product that I have used in my teaching practice since long before this contract came to light and it's a product that it would be tough for me to switch myself and everybody who uses it off of this product, because that's what everybody's used to. It's sort of considered the default. That having been said, these people are in a situation where they work on this product. The status quo is that they work on this product and they have to change the status quo in order for that to not happen. 

The status quo I've discovered is something that's really, really powerful in making decisions about our privilege. If the status quo is on our side, we don't have to argue with anybody, right? We just have to sort of throw enough sand in the gears and nothing really changes and we don't have to be that confrontational. That's why being confrontation avoidant is such a powerful tool for white supremacy is that white folks are the people who have the power and the status quo keeps them there and so, they don't have to fight to keep that power. They just have to be like kind of conflict avoidant and the system stays in place. 

We see that same thing in organizations where the status quo is already something. Changing the status quo is a lot harder than keeping the status quo and when the status quo is on the side of somebody already works in a place, there's a lot required of that person in order to get out of that situation, which is not to say that they shouldn't or that they don't want to, it's to say that there's a lot there. 

Whereas, they're interviewing me as a customer about their user interface in this situation. They want to make sure that the user interface is something that their customers want to use. As a customer, my opinion matters to this organization. It matters in a different way than the employees’ opinions matter because for me to break the status quo and move to a different product is much easier than for an employee to break the status quo and move to a different place of employment. That just happens to be the way that full time employment works. 

My opinion matters to them enough that they have arranged for four people. Instead of writing code today, they're meeting with me to find out what I think about this product. That tells me that I have some influence in this situation. So when they ask me the question, what alternatives have you considered? What features of this product keep you on this product versus other products? If you considered switching, why would that be? I know that they're referring maybe specifically to the UI and the features that belong in the product, but that's my opportunity to say, “I like the product itself. I'm aware that the company contracts with ICE; it's incumbent on me every time I talk about this company or the way that I work with this company to talk also about the fact that the company contracts with ICE. Clearly, that's not a comfortable position for a customer to be in. That would be the primary reason that I would switch.”

In those situations, what I've often found is that we're not talking about a monolithic organization where all the employees agree with the decision to contract with ICE. It's a situation where the employees are stuck and don't necessarily have the level of influence that it would take to single-handedly get the company to stop contracting with ICE. But I can be helpful to them in that regard because I'm a customer and in order to stay in business, a company has to care about what customers think. 

Because I have some rhetorical ability, I also have the ability to write down exactly what I think as a customer in a way that could be passed along to leadership and often, people at the company will ask for that. They'll say, “We are trying to fight this fight on the inside.” That's helpful to some degree, we also need this fight fought from the outside. So if you were willing to put effort into explaining exactly why you would consider switching products, that's something that you can do where your influence is valuable. 

Our influence is valuable in so far is that we can get this in front of somebody with actual power in a way that you can't because you're outside the organization. So your influence from outside the organization as a customer is valuable because you can talk about why you would switch because the status quo for you as much weaker and you can switch easily. Our influence comes from the fact that we have a direct line to the people who would care about your opinion on that. And so, we can effectively work together with our influences combined to be able to create an impact that neither of us alone would be able to do by ourselves.

AMY: I'm interested in hearing more about something that – you started to get into it, I think with talking about how your individual action can support some people who are inside of an org and how people with more power in the industry can support others with less power in sort of moving things in a direction. Most of what you've talked about, and I know that this is pretty deliberate, is about sort of individual actions, but I do think that there are some problems that I guess, I'm curious to hear. Do you think that there are some problems that need to be solved more with collective action?

CHELSEA: I think so. I think that we've seen limitation of individual action in tech a lot over the past couple of years. We’ve seen situations where a company contracted with ICE, five to seven of their top, most publicly profiled engineers all left over it. The company contracts with ICE, doubles down on their position and insists that somehow it is in line with their values as a company to maintain this contract for some business reason that doesn't have to do with keeping kids in cages one has to assume. 

Or we've seen situations where somebody who was well-known for being an internal activist at one of these large companies has worked and work for 10 or 12 years and everything looks, from outside the company, to be the picture of effectiveness from them. Then you find out this person has said an ultimatum and this person has decided to leave because ultimately, there's only so much that one person can do. 

Or we've even seen situations where organizers attempted to organize collective action and then the company took action on that. Like the way that the engineers who helped to organize the Google walkout, found themselves six months to a year later, not so mysteriously no longer employed by the company. 

So we see that there are definite limitations and unfortunately, when we put ourselves in a public and direct opposition to something that accompany with power is doing, we're often exposing ourselves to risk in those circumstances. When an individual is sort of singled out and exposed to risk in those ways, it doesn't succeed in the way that we would hope it would. In those situations, we see the limitations and realize that collective action is going to be necessary in a lot of these cases combined with individual action and combined with individual influence. 

But I think the unique thing about individual influence is that we have a lot of trouble wielding it when we are specifically focused on confrontation and confrontation is valuable, but confrontation has a specific place and it only gets us so far. The value of confrontation of course, is demonstrating not necessarily to the individual you're confronting, but to third parties. 

I forget who said this and I'll make sure that it's in the show notes, but the quote goes, “A man convinced against his will is of the same opinion still.” Essentially saying when we confront somebody, usually in that exact moment, their mind is not going to change because this defensive reaction goes up and when that defensive reaction goes up, it can be extremely difficult to change people's mind. 

I have to specifically work on being open to changing my mind when confronted, because my instinct to, even though I know that this happens, I'm not immune to getting defensive and shutting down. So the value of confrontation is less, usually, in changing the mind of the person we're confronting, but rather in demonstrating to other people, who are watching this confrontation, that something that happened in this confrontation isn't cool and people aren't just going to let it slide. So that's the value of confrontation. 

There's also avoidance, which is the other method that we usually use, and the value of avoidance usually is honestly biding our time. It's waiting in position to more influence such that we're going to be able to have some impact on this system that we don't necessarily have right now. I think that there's something to be said for avoidance, but I think it's also easy for us to use it to justify a general conflict avoidant mindset and I'm biding my time until the right time comes. 

Well, when is the right time going to come? How long are we going to be complicit with things that we don't agree with, such that ultimately, we're going to have enough power that we're going to be able to say something? When's that going to be and at what point are we just complicit? At what point are we just complicit in telling ourselves that it's fine because later, we're going to do something? To what degree can we procrastinate using our influence in that respect before it's no longer practical and is now an excuse?

That's a question that I think about a lot and what I've focused on, in this regard, lately is figuring out alternatives that are not confrontation and that are also not avoidance. That are something where we're a way to get around the defensive reaction and effectively persuade others and convince others and shift the Overton window of what is acceptable in more ethical direction by means not necessarily instead of confrontation where it's useful, not necessarily instead of avoidance where it's useful, but rather in addition to those two things? 

How do we go about convincing folks? How do we affect change in an organization where we don't agree with everything it's happening? To what degree can our influence be best used by us assisting in a way that demonstrates that we're able to talk about these issues in a nonjudgmental fashion that'll open people to thinking about how we might change the way that these organizations operate? Understanding the limitations that they're under and figuring out how to change those over time.

One of the things that I think about a lot, and this is going to bring American politics into it so I'm sorry, but is that we see the realities of a winner-take-all, first-past-the-post type of election system is that what you end up with. The fallout of that is going to be typically a two-party type of a situation because nobody else can get – there's no representative voting system to allow somebody else to get a toehold such that you're usually going to end up with two-party system and these two parties shifting their viewpoints according to basically what 50% of the population is prepared to get in line with. Because as soon as that 50/50 balance shifts, the parties shift to get back towards that 50/50. If any one gets ahead, then they're both shifting in a direction and we've seen that over time. We've seen that over centuries, right? 

We have these two parties in the United States. We call them the Democratic and the Republican parties. There are situations where say, 60 years ago, a position of one party today was totally the position of the other party 60 years ago on this specific issue. So a lot of social change has to do with broad attitudes around stuff, as opposed to specific platforms, because we see power changes hands every like 4, 8, 12 years or so between these two parties in government. 

We have this tricameral situation where there are sort of three areas of government and their party shifts between red and blue, red and blue over the course of a 100 years. But that doesn't mean that society hasn't changed in that period of time, what it means is that the parties have shifted to embrace different goals because it’s society and what people are willing to vote for has shifted as well.

So I think about that a lot with regards to tech as well is that we have these kinds of power systems, sure. But those power systems to some degree have to abide the slower changing, but ultimately, powerful undercurrent of what the whole of society is going to accept. There are statements that politicians could make in the 40s with impunity that they can't make with impunity net, or at least nobody would have mentioned them in the 40s. Whereas now, if they were to mention, that would be a big deal. 

That's something that I think about a lot in tech is to what degree can I influence the larger, more slower moving current of what we are prepared to accept in such a way that norms 25 years from now are more ethical than norms are right now? What can we do about that? That's something that I think about a lot and I can't report to have all the answers on that, for sure. But that's sort of what I find myself thinking about more than immediate changes to contract lists these days.

AVDI: Yeah. That makes me think of, we have seen shifts of that kind in software over the past several decades. One that always comes to mind for me is the shift to open source software where the norm has shifted from giveaway software. We don't give away our intellectual property. We try to build as much stuff on open source as we can and companies are cooler if they give away lots of software. While the explicitly named open source movement was an attempt to depoliticize [inaudible] movement; originally, that as an explicitly political project and it succeeded.

CHELSEA: Yeah. 

DAMIEN: Yeah.

CHELSEA: This is a thing to think about open source in that regard. Damien, what were you going to say?

DAMIEN: No, I just wanted to call out how incredibly valuable that framework is. Instead of moving a politician, a platform, a company, a policy, an election; moving the actual norms of society is slower and more difficult. It's hurting planets instead of bison, but it's so much more powerful and of course, the person who is a prolifically lexical, as you are, that's something that is in your wheelhouse, I think.

CHELSEA: I like that term, prolifically lexical.

DAMIEN: Yeah, that was kind of embarrassing. I can't believe I said that.

AMY: No, that's fantastic. That’s now like goals, hashtag goals, prolifically lexical. Sounds much better than talks a lot, which is how I think of, and I'm sorry. I'm not – [overtalking]

CHELSEA: It's true. I write too ding dang much, I talk too ding dang much, but I've started live streaming a lot lately on code. I don't know, I'm always shocked when people watch. I'm like, “Why does anybody want to watch me narrate myself writing code? How interesting could this possibly be?”

AMY: By capitalizing on the fact that people are interested in that and that because of that, you have the opportunity to shift things because people want to hear you.

DAMIEN: And the more visible you are and the more seen you are and the more heard you are, the more the norms move to where you are. To use an example of power field from where we are. I live in Southern California. I have a Southern California accent. Most of the United States has a very close to a Southern Californian accent. Most of the world speaks very much like Southern Californians because we make television and movies here. 

CHELSEA: Yeah, that's a really good point.

AMY: Oh wow, that just blew my mind. [laughs]

CHELSEA: Yeah. That's absolutely the case. 

It's funny that you should mention that because I was talking to – I sing, I have a singing lesson on Friday morning. That happened earlier today and we're working on a song right now. It's called Hurricane by The Band of Heathens, if anybody's interested. The band is great. They're from Austin, Texas. The song is about resilience, ultimately. It's a song about resilience and the story of the song is about this Cajun man. You presume from the story; it sounds like he's like an older Cajun man from a previous generation kind of who grew up on the Pontchartrain. Pontchartrain is a lake in Louisiana, it’s in Southeast Louisiana. 

Now, my father was born and raised in Louisiana in an entirely Southwestern Louisiana family. So I come from some Cajun roots and I'm going to tell you what, the lyrics of this song—the band is from Texas. I do love the song. I can also acknowledge that the lyrics of the song are completely not accurate the way this old Cajun crab would talk. They are so inaccurate to the way crab would talk that if you change the song to make it sound the way the he would, the whole meter and rhyme scheme of the song doesn't work anymore. 

I have tried it. The rhyme scheme depends on pronouncing things in, effectively, a Southern California accent despite the fact that we're supposedly talking about a man who has not left the shore of the Pontchartrain his entire life. It's just funny to me to sing that song because as I sing it, as I sing this song about my homeland, I find myself shifting into the accent into the voice that this man would talk in and I have to pull myself back and be like, “Stop! The songs not going to work if you go too far in that direction. You cannot do this or else, the whole chorus is going to be off and we're going to be screwed.” So it's an interesting sort of internal battle that I fight with my instincts on how to talk like this guy and how to sing the song “correctly.”

JESSICA: Always a challenge between what we know is right and what fits in the system we're in. 

CHELSEA: Yeah, exactly. [laughs] Exactly!

JESSICA: Okay, it's like almost time so we should we should wrap up. At the end of the show, we usually do a round where everyone can reflect on one thing that struck them in the conversation; something they're going to look up further or some point that they didn't get in earlier. This is fine, too. Who wants to reflect?

AMY: Probably when you were talking about confrontation and avoidance, and the reasons we might choose one of the other at any given time, and the space in between in terms of influence and I started thinking some about the ways that people could be both competitional and avoidant at the same time. For example, work slowdowns or just ways that people with less power can nevertheless kind of throw sand in the gears of things that they don't agree with without being confrontational. So I want to think about that more. 

DAMIEN: I'm going to pretend that this is one reflection somehow so if it doesn't make any sense, that's why. We started with this idea of, I think you used phrase software detective work or forensics and it really opened my mind to the breath of the work in tech and how we have all these different roles, a little QA and acceptance and business analysis and engineering. And how so much of it is learning, discovering knowledge, creating a shared understanding, figuring things out and that the lines between them are incredibly fuzzy. Then that expands out to the broader system of how what we do impacts larger systems and then how we can actually use that to move entire societies and like that is actually possible and something we can work towards. That really did sound like one thing; I'm very proud of myself. 

JESSICA: Yes, that was beautiful. Great summation of the show. Avdi, you have anything?

AVDI: No, I'm still chewing on all that. 

CHELSEA: Something that Amy said earlier in the conversation about the fact that if everybody's working together, well, then you don't have a job as a manager and relating that to the fact that if all software worked and we understood how it worked, none of us have jobs. It makes me think a lot about the degree to which our fallibility creates the positions that we get to occupy and what that means about the grace that we need to have for the fallibility of other people because to some degree we depend on that fallibility.

DAMIEN: Wow.

CHELSEA: Yeah, there's two parts to that; the mistake has to have happened and the person has to be willing to tell us that this thing is wrong. That also means it’s incumbent on us to have grace, too because if we're not prepared to do that, why would anybody admit to us that they had made a mistake and how would our help be valuable if nobody can admit it to us without us making them feel terrible?

DAMIEN: Wow.

JESSICA: Can I just remark that Chelsea, you sing, too? That's ridiculous and you're a super CrossFit person and tech and leadership and systems and social change and also, you’re hilarious and I am very happy to spend time with you because you're awesome. 

CHELSEA: [laughs] I should have you write my bio for my dating profile; you’d be much better at it. 

[laughter]

CHELSEA: Basically, all I've written on there is, “If you bring me a latte at the right time, I'm putt yin your hands.” That's the only key, I'm very easy.

JESSICA: Awesome. Thank you so much for joining us today.

CHELSEA: Yeah, that was good.

JESSICA: A fabulous episode.

CHELSEA: Yeah.

DAMIEN: Thank you so much.

CHELSEA: Yeah, thank you. This was great. I loved chatting with you all, always.

AVDI: Thank you so much, Chelsea. All right and I would be remiss if I did note, if you want to continue this conversation, please join us on the Greater Than Code Slack, which you can get onto by donating as a little as a dollar to our Patreon and you can join other listeners and panelists and often, the guests as well for a lot of really cool conversations.