064: Stories, Bias and AI with Aditya Mukerjee


Jamey Hampton | Sam Livingston-Gray

Guest Starring:

Aditya Mukerjee: @chimeracoder | adityamukerjee.net | Identity Hackers

Join Our Slack Channel!
Support us via Patreon!

Show Notes:

00:58 – Aditya’s Superpower: Parking Karma

03:18 – Algorithmic Decision Making in Machine Learning and Artificial Intelligence

09:06 – Recognizing the Effects of Bias

The Bias Blind Spot

The Babadook

18:07 – Health and Technology: How can technology have a meaningful impact on care delivery?

23:54 – Why are people frightened of automation?

33:33 – Storytelling in Software and Engineering


Sam: Be a little bit more aware of how stories are told.

Aditya: Thinking of yourself as an editor for the story.

Jamey: The difference between can we build this and should we build this?


JAMEY:  Hi everyone! Welcome to Episode 64 of your favorite podcast, Greater Than Code. I’m Jamey Hampton and I’m here with my fellow panelist and good friend, Sam Livingston-Gray.

SAM:  Hello, hello. I am pleased this morning to welcome Aditya Mukerjee to the show. Aditya is an entrepreneur, investor and engineer based in New York City. He studied Statistics at Columbia and Computer Science at Cornell and was once a nationally ranked wrestler, so there’s really nothing he can’t do. He enjoys playing German-style boardgames and listening to embarrassing music. You can believe we want to know more about that. And he organizes identity hackers, which is a group for LGBTQ+ engineers in New York. Welcome to the show.

ADITYA:  Thank you. Thanks for having me.

JAMEY:  So, we usually like to start off our shows by asking our guest, what is your superpower and how did you acquire it?

ADITYA:  So, my superpower is the ability to find really great parking spots when I’m driving. So, back when I still lived in Boston and owned a car, I was going with some friends to a concert. We were seeing The White Stripes at Agganis Arena which is in Boston. It’s a massive arena. It seats like 8,000 people. And we were running late for the show and so, we had no idea where to find parking. But I just put in my GPS where the arena is and so we drove straight there. The show started at 8. We arrived at 7:40, driving right in front of it. I would say probably 20, maybe 20 feet from the front entrance, it was perpendicular to the entrance, there was no way to find a spot closer to the curb. We found an empty spot with metered parking and we parked there. In addition we found that there was… it was 20 minutes to 8 meters. You don’t have to pay after 8 in Boston. And there were already 30 minutes left on the meter at that point. So, we did not even have to pay.

SAM:  Nice.

ADITYA:  We parked there, walked 20 feet to the front entrance, and got in. Of course, this is a superhero power which while useful at times is almost never needed for me in daily practice anymore because I live in New York and I don’t own a car. That’s kind of a waste.

JAMEY:  Does it work if you’re a passenger in someone else’s car or do you have to be driving?

ADITYA:  It’s mostly when I’m driving, yeah.

SAM:  Yeah, my partner has the same superpower and I often make her drive two places. And I say, “Well, I’ll drive home but you need to be able to find a parking spot where we’re going.”


SAM:  It’s super useful, though. It’s great. So, is this something that you just, you got your learner’s permit and immediately started finding rockstar parking or was it something you developed over time?

ADITYA:  Yeah, no. It was just as soon as I got my license, it happened everywhere. I would get amazing parking spots. I don’t really miss driving, living here and taking public transit everywhere. But it almost does make me feel like I need to drive every now and then just to keep up my powers.

JAMEY:  Amazing.

SAM:  So Aditya, what’s on your mind these days?

ADITYA:  So, one of the things that I’ve been thinking a lot about recently…  so my background is in statistics and machine learning and artificial intelligence are pretty hot buzzwords these days. But it’s really important for us also to take a step back and think about the ways that we’re introducing algorithmic decision-making into our daily lives and what some of the potential pitfalls are. And some of them we’re actually already starting to run into. One of the biggest dangers is that just beyond the technology and beyond how well-designed any given algorithm is or any given say, recommendation engine, we also need to understand how it affects our perceptions of the tools that we’re using.

So, to give you an idea, if you present someone with a decision and tell them “This is a decision that I made,” they’re a lot more likely to question you and to be skeptical of that than they are if you say “Here is a decision that was made by our computer, made by our computer systems, made by our recommendation engine.” We’ve trained ourselves to trust computers to a degree which may or may not actually be deserved. Computers aren’t infallible. Computers are programmed by humans and the recommendations that we teach computers, computers are very good at learning all of the same cognitive and other biases that humans themselves have. The problem is that computers are a lot less explicit about it, sometimes. When they are explicit, it’s sometimes amusing. But oftentimes it can hide itself. And that’s really dangerous, because we don’t, as human beings, we’re not really trained to recognize problematic decisions or biased decisions in algorithmic decision-making the same way that we are trained all our lives to recognize that when it comes from another human.

To give you just an amusing anecdote around this, I took a screenshot of this. I was watching Netflix a few years ago and it gave me… Netflix shows the top things that you might like and it tells you the reason. So, it recommended for me ‘Barney Sings the ABCs’ and the reason that it recommended that was ‘because you watched Law & Order: SVU’.

SAM:  Naturally.

ADITYA:  So, it’s very easy to understand where that decision came from. A lot of parents will watch ‘Law & Order: SVU’ and then let their kids use their Netflix accounts. And if they’re not always signing into the kid’s profile beforehand, you can easily see how those two things become very highly associated with each other. But if you take a step back there, it’s a little bit creepy to recommend those two things in tandem, first if all, but also it’s almost never appropriate. There’s almost no one who actually wants to watch ‘Law & Order: SVU’ and also wants to watch ‘Barney Sings the ABCs’ themselves. They might put it on for their kids, but you’re not actually presenting them with a reasonable decision. And so, this is what I mean. We’re trained to recognize in this case a very obviously bad decision and so it’s kind of funny. But when it’s a little bit more nuanced, when you’re presenting things to people that might contain remnants of human bias but not in such an explicit form, it’s a lot harder to recognize.

JAMEY:  Do you have an example of that?

ADITYA:  Yeah. There are a number of ways that this pops up you might see on social media every now and then, because it particularly happens with regards to LGBT media and also media that is, I would say adult-oriented. Not necessarily pornographic but might feature adult themes or nudity, but not necessarily explicitly pornographic. And we don’t… a lot of times algorithm, the algorithms that we build don’t readily distinguish between those two things.

So, this has happened a few times where Amazon and YouTube had each repeatedly purged the channels or products that are just books or channels about LGBT life or books written by or about LGBT characters. And it’s very obvious what happened there. And oftentimes to give them the benefit of the doubt there, I don’t think that someone at Google is actually sitting there and going through and removing all those channels because of explicit anti-LGBT bias. There might be some people there, but I don’t think that’s what’s happening systematically. What’s really happening is that we had these assumptions that LGBT and adult themes and pornography are somehow all connected, even though they’re not, in daily life. And so, we encoded that very implicitly into our algorithms.

Of course, it’s hard to actually pinpoint this. And this is one of the problems with machine learning getting more advanced and our tools for AI becoming smarter but also becoming more difficult to dissect and to reason about. We see this a lot with using neural nets for translation now. And we’ve reached the point where neural nets can be used to translate… they say it’s used to translate whole sentences. What they really mean there is that they don’t actually know the components of each step that’s happening. So, it takes a sentence and then spits out another sentence on the other end. That doesn’t mean it’s translating the whole sentence. It just means that they don’t know like, we’re translating one word at a time or phrases or words. It’s basically become a black box.

And we know that as humans we have these biases. We have these preconceptions. And we also know that we’re the ones who are training these algorithms. So, it’s pretty reasonable to think that we’re training them to act like we do. But the difference is we can’t pinpoint anymore to specific parts of that behavior and say, “Here’s where you made that decision wrong,” the way you could with a human when if you say, “This is the bad decision that you made. Here’s why you made it and here’s why it’s wrong.” You can’t really do that with a computer, because it’s not how computers work.

SAM:  That reminds me of something you said earlier about how we are not as good at recognizing the effects of bias from a machine decision as we are at recognizing bias in decisions made by others. And I found it very telling that you didn’t say, “Recognizing bias in decisions that we ourselves make.” That reminded me of one of my favorite cognitive biases which is called the bias blindspot. And I’ll just read the first sentence of the Wikipedia definition. It says “The bias blind spot is the cognitive bias of recognizing the impact of biases on the judgement of others, while failing to see the impact of biases on one’s own judgment.” And the other thing I was thinking about with that was that if we look at the decisions that a biased AI puts out, if they agree with our own biases, we’re going to look at that and say, “Oh, that’s totally fair,” unless we’ve been specifically trained and are actively looking to counter our own biases, and we know what they are.

ADITYA:  Exactly. It’s very hard for us as individuals to recognize our own biases. And in some way I would say it’s actually even harder for us to do it if we’re the ones who are writing, for those of us who actually write these systems that make these decisions. It’s harder for us to recognize because we have that attachment to it. It’s the same introspection problem, but then of course at the other level. We’re no longer reasoning with a human being. We’re no longer reasoning with something that we actually are trained to think about in that level. And it’s something that I will say, it’s also a bit of a problem in how we teach these topics.

So, we talk about statistical bias as something that doesn’t really have actually the same meaning as the word ‘bias’ in colloquial speech. But when we talk about how to construct models or we talk about… when we learn the fundamentals of statistics and of machine learning, we don’t actually spend a lot of time on something that’s really critical to the field which is, how do you actually reconcile a problem statement, like something that comes up in the real world, with the actual concrete steps in the models that you build to solve it. We do it at some level sometimes but there’s not as much of a focus as I think there really needs to be. Because that’s the crucial part of it.

Building models in some sense is easy. Building statistical models is kind of easy. But actually evaluating whether or not those techniques really do solve the high-level problem that we care about, that’s a lot trickier. And if anyone says that that’s actually easy, I would really challenge that because it’s probably a sign that they’re not actually thinking about it in as much depth as they really need to. You almost can’t think about these things too much because there is no one-size-fits-all framework for it. And that’s what makes it so challenging.

SAM:  And part of the reason that we use these statistical models is specifically because they’re good at finding those weird connections between things that a human might not consciously notice, right? But by the very same token, that also means that the models themselves are very opaque and difficult to reason about, right?

ADITYA:  Exactly. The exact thing that makes machine learning powerful, the fact that it can recognize things, recognize patterns that humans cant, and the fact that it can do so very fast, is exactly why it’s so dangerous. If you have a whole crew of people who are reviewing YouTube videos on a daily basis, if you have one bad actor in there, and bad actor doesn’t mean malicious, just you have one person who’s making bad decisions, their impact is going to be pretty small. If you have that same person training a system to make those decisions, their impact is obviously going to be much wider.

SAM:  Congratulations. You’ve just scaled a bad actor.

ADITYA:  Exactly. We don’t really put much thought into that. When you put it in that way, if you say would you take someone who has a history of making these bad decisions and put them in charge of an entire team that’s responsible for that, you’d say no. It still happens, but we would pretty much readily agree and recognize that that’s a bad idea. But if you say, “Would you take someone who has no experience with making these decision or that has not proven themselves to be thinking about, in this case again, YouTube videos, in an unbiased way, in a way that’s actually in line with the values that we ourselves hold, would you have them design an algorithm for flagging those videos? There would probably be a lot less hesitation around that. And there needs to be. It’s not something that in product development in general, we’ve really trained ourselves to incorporate as something that we look for in who actually designs and develops and builds these products.

JAMEY:  It’s interesting to me that you use the word dangerous because one of the things that’s been on my mind as you’ve been talking is the possibility of creating a biased feedback loop almost. Because we build these machines and we maybe accidentally put our biases into them. But then because people are less likely to question machines, putting that out, put out into our world, our society, I think is likely to re-cement those biases in other people. I was thinking about that originally when you were talking about Netflix. I think this all ties in because there was a mistake on Netflix a year ago where they accidentally categorized the Babadook movie as an LGBT movie. And that was funny. It was kind of funny, and people in the community…

ADITYA:  I remember that.

JAMEY:  Were like “Yes. The Babadook is our new gay icon.” It was a funny meme. But it did change the way that people thought about that movie. I know a bunch of people who watched that movie only because of that. So, that’s not maybe necessarily dangerous. That’s just a joke. But then I think when you’re talking about flagging YouTube videos and this idea that LGBT themes are related to adult themes and pornography, once they’re getting flagged in that way and people are seeing that, I think that’s reinforcing this fetishization of it.

ADITYA:  The Babadook is a very good, it’s a humorous example. But it’s something that we already seeing the ways that life is influenced by algorithmic decision-making. And there is that feedback loop that you introduced. It’s not too hard to imagine a second order filter bubble. You’re familiar with the filter bubble as a concept where you have Google or Facebook for example essentially presenting different views of the world, essentially, to people because of what it thinks as people would be interested in. But of course, you’re interested in things that you see and you develop more interest in things that you’re exposed to. And what is the 10th or 11th or 100th or 1000th layer of feedback recursion there? We don’t really know where that all leads. But it would be irresponsible of us to design these systems and not think about that at any point.

The other aspect of this is sometimes the connections that we draw with our decision-making may not actually have the same semantic contextual or cultural meaning that we actually want to express. Another example of this that happened a couple of years ago was that for a while if you searched for LGBT dating apps on, I think this was on Android but it may have been iOS, on either app store, one of the top recommendations that you would get was actually for a gay conversion app. And on some level, you can see why yes, those two things are connected. There’s a very clear connection between those two. And you can even see why people who are interested in one might technically be interested in the other, not for the same… they might not be interested in using it. They might be interested as a point of contention or something that they’re focusing their outrage on. But there is still a degree of connection there. Of course, we haven’t taught a machine to recognize what the contextual meaning of surfacing those two together is.

And we haven’t done it because it’s hard. But of course, just because something’s hard, that doesn’t mean that we shouldn’t be trying. I’ve seen very little interest or research into how to encode contextual and cultural meanings into our model-making, into algorithmic decision-making. They’re oftentimes introduced as a second layer. Like we’ll have a human check certain results or we’ll have a flagging system. And that’s okay. But that’s sort of a cop-out answer to say “We’ll still have a human checking this.” It’s not that it’s impossible to teach machines how to understand culture and how to understand context. We’re taught machines how to understand language, for some definition of understand. We just need to focus our attention in making sure that the cultural and semantic meanings of, in this case recommendations or decisions that we’re surfacing, again that they represent the values that we actual set out to uphold.

SAM:  Right. And putting a human in the loop really just brings you back to the same scaling problem that you had that caused you to introduce the machine in the first place.

ADITYA:  Exactly. Another place where we see this manifest at a much more technical and also a level where there are much higher stakes is in medicine and care delivery and health tech. So, this is also something that I’ve thought a lot about. Before my current job I actually founded a health tech company and I worked on that for a couple of years. And it’s something that I’m not in the health tech industry right now for a number of reasons, but I still recognize that it’s a very important… there’s a lot of important work to be done there. One of the challenges that health tech has is in adapting to algorithmic decision-making. Medicine is a field where there hasn’t really been a whole lot of algorithmic decision-making historically because there actually just hasn’t been a lot of data. We have a lot of data but from a clinical standpoint, not all of it is necessarily very useful. I can explain what I mean by that in a moment. But to drive home the algorithmic decision-making part, it’s actually affected the types of treatments and medical care that is available.

A lot of the research that’s done on treatments is done on either very, very specific segments of populations based on disease categories. So for example, African Americans who are suffering… overweight African Americans who are suffering from diabetes. That’s a very specific category. Or they’re done with a very general population like people over the age of 65. And of course in medicine, you’re not dealing with aggregates as you practice medicine. You’re dealing with individuals. And different individuals have so many different intersecting needs and comorbidities and medical histories that you actually really do need to tailor treatments, particularly for more complicated conditions, to individuals. But we don’t have the means to take the data into account, because that data may not exist. It may not be ethical to collect.

And it may, the dimensionality may be too high. I actually heard the CIO of Weill Cornell Medical College once say that once a patient is on three or more medications at a time, there is no evidence-based medicine, which is a really scary statement. Think about how many people take three or more medications on a regular basis. And medications in this sense could even include caffeine or alcohol, drugs that people take that they aren’t necessarily prescribed. Most of the population is on three or more medications on a regular basis, certainly most people that are receiving medical treatment. And just looking at the… as engineers we understand what it means for things to explode exponentially or combinatorially. And that presents a real problem because even if you had a hundred billion humans in the history of humanity and we collected really granular data about every single one of them, we may still not have enough data points to generate the decisions that we need to.

So, what do we turn back on? We turn back to very general studies, which then fall into the opposite problem that they fail populations that are not well-represented there. We’ve seen this happening in… psychiatry is a field where this particularly pops up. It turns out interestingly that there is a certain enzyme that’s needed. I forget the name. It’s not a particularly memorable one. It’s needed in order to catalyze a lot of psychiatric drugs. So, most antidepressants, most antipsychotics, a lot of really common psychiatric medications. If you don’t have this enzyme, you can take that medication but it won’t have the actual desired outcome. You’ll just get a lot of side-effects and you won’t have the actual intended effect. You might be able to see where I’m going with this. It turns out that that gene is not evenly distributed across the global population. It turns out that it’s common in… over 80% of people of white European descent have that gene. I think it’s definitely under 20. I think it’s under 10% of people of African descent have that gene.

And even there, we see the problems of collecting this data. What does “of African descent” mean? What does “of European descent” mean? Those are very broad categories. But we already can tell that there’s an issue there. And so if we wonder why certain outcomes… like we see the different results in medical care for black Americans in the US and also different things like higher rates of homelessness, higher rates of other associated things like crime or incarceration, those things oftentimes can be tied to, maybe not directly to, things like mental health. But indirect causes of that stem from untreated medical conditions, can be a contributor. And if we’ve recently realized that we actually don’t even have the means to treat a fairly large and underserved population, segment of the population, with most psychiatric medication, where does that leave us?

And of course, the reason, bringing this all back, the reason that we’ve arrived here is because of the limitations of statistics, the limitations of, I wouldn’t say statistics as a discipline, but the ways that we apply it within medicine. And again, a lot of those limitations are fairly understandable. Some of it’s the state of the world. We can’t invent more people just to do experiments on in the way that we can do experiments on computers or physics in a lab. There are a lot of ethical concerns around it. It still has lots of [inaudible] impact. And if you want to start talking about making algorithmic decisions about treatment based on that same kinds of data that have already led us to these problems that we see even with humans interpreting that data and applying it, you can see where the potential for negative feedback loops, Jamey as you mentioned, where we’ve started. We can start to amplify that to a degree that becomes really disastrous for society at large.

JAMEY:  I have a question that’s kind of related but not extremely related to everything that you just said.

ADITYA:  Sure.

JAMEY:  So earlier, you said that people are more likely to trust computers’ decisions than they are other people’s decisions. But we also talked about the three medications and how you can’t have that kind of…

ADITYA:  Evidence-based medicine.

JAMEY:  Yes, evidence-based medicine. Thank you. And I’m wondering, the question that this is turning up in my mind is, how do you think the general population feels about automation? Because in my experience I feel like people are frightened of automation, in a lot of ways. And then when you were saying about people trusting computers’ decisions, I was like “That makes sense.” But also I think people are afraid of automation and I’m wondering how that fits in together for you.

ADITYA:  I think that I would draw a distinction between automation, automation in the sense of something like self-driving cars. That’s automation. But that’s not really algorithmic decision-making. Obviously there are algorithmic, decisions that are being made algorithmically in the process. But people don’t think about that as… the problem that we’re solving is not the problem of how to make a decision algorithmically. The problem that we’re solving is how to get from point A to point B. That’s different from saying the algorithmic decision of “How do we treat this person’s cancer?” or “What dosage of this medication do we give?” And you can easily reframe those two problems to be equivalent. So, instead of the question of “What dosage of this medication do we give?” the problem is “How do we keep this person alive?” But that’s not the way just for whatever reason that we as humans think about those problems.

And so, I think that people are probably more afraid of automation on a day-to-day level than they probably need to be. Something like cars. Cars are actually already largely automated. They’re not self-driving yet, but the cars that you’ve been buying for 15 years, so much of that is… there have actually been computers…

JAMEY:  Cars is what I was thinking of, too. Because…

ADITYA:  Yeah.

JAMEY:  People are like “Well, if there’s going to be an accident, can you shift back to manual control?” And I’m just thinking like “That’s exactly when you don’t want to shift back to manual control.”

ADITYA:  Yeah.

JAMEY:  The car is going to be better than you at that.

ADITYA:  Exactly. And in fact, that’s the part where we’ve already automated. Those are the parts of driving that we had automated for 10 to 15 years anyway. And people aren’t afraid of that because that’s not the way it’s presented to them. But people are not afraid of those decisions because they’re not presented in that way, but they are afraid when you present it as a problem of automating the process of driving because it’s a process of integrating all of those many algorithmic decisions into the overall end result of automating an action where people’s, I think, expectations and fears don’t always align one-to-one with what’s going on.

And I wish that people were, I think, a little bit less afraid of that kind of automation in the integrated sense, and a little bit more skeptical of the individual decisions that… algorithmic decisions that are going on. I do trust my car. But I don’t necessarily say a recommendation engine to provide me with what I want. And I certainly don’t necessarily trust a computer system that’s going to say “Here’s the medication that I think you need in order to treat your condition,” because I have very low confidence that it’s taken all the right appropriate variables into account. I don’t necessarily have that confidence in a given physician either, but at least I have the ability to talk to that physician and engage in a dialog there. You can’t really engage in a dialog with a large system that’s engineered by many people simultaneously.

SAM:  Yeah, I can’t even keep track of code in applications that I’ve written. I can’t even imagine what it would be like to try to track down code in Watson for example.

ADITYA:  Exactly. Watson’s a really great example of the power of these, the raw power of these tools. Something like solving Jeopardy, or sorry, solving the problem of how to win Jeopardy is a very well-scoped problem. There are very few societal implications to that directly. And it’s a pretty binary decision. You know whether or not Watson won. But it’s that next step of taking those decisions that it’s making and figuring out which problems to apply them to and whether or not they actually solve our societal problems where it starts to break down. I might want Watson to win Jeopardy for me if I ever got on Jeopardy and I could enter Watson in my place. But I might not want Watson to, in fact I definitely would not want Watson to be outsourcing all decisions for my own personal medical care or even something like my personal finances.

That’s something that’s, to bring it a little bit way from medicine because that’s only one aspect of it, personal finances are also, they’re fairly objective to a degree. You can measure your result in a way that most people would agree on. And there’s a lot of automated decision-making that happens within the finance world. But on an individual level, we still actually haven’t solved that perfectly. Because there are a lot of different things that people care about with their money. Where their money should be, when they have access to it, what types of things they want to support with it, maybe ethical constraints about what things they want to invest in. And those are things that are very hard for us to take into account with the ways that we currently design our computer systems.

And again, that’s not to say that we can’t take these things into account. But we haven’t built all of those systems. We haven’t built all those systems yet. If there’s on ray of light or glimmer of hope I can point to here, it’s that medicine in particular is a very difficult problem. We’re not going to solve that, the problem of algorithmic decision-making in medicine, any time soon. But with finance, we might. With finance there’s a lot more data to be collected and there are far fewer ethical constraints about collecting it. And a lot of the lessons that we learn from the finance world about how to manage things like individual decisions around managing money, could be applicable to how to manage individual decisions about health. And again, I’m talking about the structural technical models that we’re making, obviously not the exact decisions themselves.

And one other thing, if anyone came to me and said that they were interested in health tech and figuring out what sorts of problems computers and statistics could actually help solve, it’s actually very funny that some of the biggest open questions in medicine and in care delivery are actually the most fundamental ones. We’ve developed things like, some medical treatments that are out there are absolutely mind-boggling how advanced and how complex and how well they work. But at the same time, one of the largest unsolved problems in care delivery is a cost-effective way to intervene in someone’s health and get them to change their decisions.

So, a very easy and obvious example is being overweight or being obese is very strongly linked to a lot of other conditions like diabetes and heart conditions and all sorts of other things. And obviously, holding everything else equal for a person who’s overweight, if they lost weight and attained a healthy weight, they’re much less likely to develop many of those conditions. We don’t have a cost-effective way to get people to change their behavior because losing weight obviously requires a lot of active effort on that person’s behalf.

SAM:  If it’s even possible at all. There are certain medical conditions that make it difficult, of course.

ADITYA:  Of course, yeah. And I’m speaking… and thank you for pointing that out. I’m using this as an example for a couple of reasons, one of which is that diabetes in particular, it’s comorbid with so many other conditions, which means that it appears alongside many other conditions that it’s oftentimes used as the go-to example of a particular medical condition that affects a wide range of people simultaneously. Because it’s not restricted to ethnicity or gender or sex. It affects a wide swath of population. And at the same time, it’s also largely potentially prevented through lifestyle [reasons] or the flip-side of that is it can be very easily exacerbated by decisions that an individual can make. And we don’t have an effective way to intervene in people’s health. If you see someone who’s in their 20s, we don’t have any mechanism that is both reliable and cost-effective across a wide section of the population to get them to change their behavior. There are individuals who might choose to, but we don’t have any means that that scale across a population.

And again, this is not… losing weight is just one particular type of intervention and for one disease category. There are many others. But even something like that, we don’t… it’s been a big open problem in medicine for 50, 60 years. There’s a lot of potential for technology to augment that decision-making process, a lot open potential there. We just haven’t actually tapped it yet. That’s where I think that the power of statistics and machine learning can really impact medicine and care delivery, if someone wants to. But we need to start investigating and building the structures that allow us to tackle these problems in the first place.

SAM:  So, one of the things that we discussed before you came on the show was the idea of storytelling. And you’ve been using stories to illustrate some of your examples. But I really wanted to talk about the importance of storytelling to programmers, because I feel like it’s something that is really underappreciated.

ADITYA:  Sure thing. So, the way that I think about it, storytelling is a life skill. It’s not just a career skill or technical skill. And so, it’s useful to programmers for the same reasons that all life skills are useful to all people. And there are some ways that it can in particular augment our daily work. But storytelling is how people communicate. I’m Bengali. I grew up, we have a very strong culture of storytelling. It’s actually so strong and so ingrained that even though I was born in the US, I grew up in the US, it took me until… growing up I never realized how much storytelling isn’t as explicit a part of broader American or western culture the same way that it was for us growing up. Because it was so ingrained in us. Telling stories is the way that you have a conversation. For us, it is the way that you have a conversation. It is the way that you convey expression or meaning. And so, that’s a little bit of my personal bias of where I’m coming from.

But I’ve also noticed that it’s a very powerful communication tactic and also career or professional skill to have. The ability to illustrate data with stories is crucial. As a statistician I can give you whatever figures and facts and numbers that you want, but unless I’m actually able to craft them into a narrative, it’s not going to actually resonate. you’re not easily going to remember it afterwards. And for engineers, storytelling is the way that we can actually apply meaning to the code that we’re building. I can write amazing, solid code to solve a problem. But unless I’m able to convey to you the importance of that or the meaning or the reason that it solves some technical problem, you’re not really going to understand it. You’re not going to be convinced to use it. If you’re a product manager, if you’re a CEO, you’re not going to be convinced this is something that’s worth investing in.

And storytelling, more broadly, it’s not just a matter of, we think about stories as things that have a start, a beginning, and end. Like there is a climax somewhere around there. There’s a conclusion at the end. And that’s not the way that stories have been practiced. Storytelling is, it’s the way that we connect the dots of our life. If we think about all the different actions we take on a daily basis, if you think about this in little dots, storytelling is “How do I actually synthesize those into a coherent narrative?” And so, when you’re having a conversation with say your manager about why you’re working on the stuff that you’re working on, or why you want to work on some stuff that you’re not working on, that’s a matter of storytelling. And people think about that as negotiation skills. People might think about that as logic and reasoning and argument, like the skills of having a rational argument. That’s all true. But it all boils down to the art of telling a story at the end of the day.

And it’s not because… there’s a tendency for engineers in particular to look down on this because we think of storytelling as appealing to emotion and we think of emotion as bad and we think of emotion as being antithetical to rationality.

SAM:  Because we all secretly want to be Spock. Except that would be a terrible idea.

ADITYA:  Exactly. We have these assumptions about emotion and reasoning as somehow being incongruous with each other, which are really damaging. And they’re also just incorrect. Telling a story to convey a narrative is not a way of concealing logical data. It’s a way of highlighting it. Another way to put it, so I work on the observability team at Stripe. And I’ve got… observability, we are responsible for providing engineers with the tools to investigate their code, investigate their systems, and understand why… is something failing? Answering that question, answering “Why did it fail?”, “What do I need to do to fix it now that it’s failing?” The ability to explore the internal state of their systems.

And one of the tools that people use to do that are logs. But log files are actually a pretty bad way to deal with this data at scale. Because sure, if you have a distributed system that has a thousand different machines in your cluster, yeah you could tail all of those logs and look at them. But it’s not going to give you anything useful. You could grep through them. But that’s still not going to be a really great way of exploring data. You need some sort of narrative that you’re going to extract from it. Because if you’re analyzing what could be hundreds of megabytes or even gigabytes worth of log data per second, no person is going to be able to analyze all of that. And storytelling is analogous to the process of taking all that log data and extracting it and synthesizing it into summaries or aggregates.

And so, I don’t view storytelling as something that’s somehow disconnected from the rational, empirical, data-driven work that we do on a day-to-day basis. It’s the way that we actually take that empirical, data-driven work that we do on a day-to-day basis and then make it useful to humans. Which is, at the end of the day, who we’re actually serving.

SAM:  Yeah. I see storytelling also as a way that I can help educate my fellow engineers. So, if there’s a bit of code that has been historically very problematic, I need to tell the story about why that code sucks and how I was able to change it and make it more palatable. And I need to have my fellow engineers understand how that happened, how the new solution works. And I can’t do that by just saying “Okay, here’s the new code. Sit down and read it at your leisure.” It really helps if I’m able to say “Well, here’s this one thing that was hard. And I took this trick and I applied it here and it made this one thing a little bit easier.” Tactically I also use it, I also use storytelling in Git commits. So, if I’m doing one of those big refactorings, I could commit the whole thing all at once. Or what I find is often much more useful is I’ll take each individual step of that refactoring and I’ll commit it individually. And then people can say “Oh, this little thing changed. And then that little thing changed. And then that little thing changed. And that made this clearer. So, I was able to change that other thing.” And then by the time you reach the end of the story, you understand how you got there and why the thing works the way it does.

ADITYA:  I really love that, the example of Git histories in particular, because it really strikes an aspect of this that I find very powerful. Yeah, the code… as I said, all the actions we take on a day-to-day basis are these data points that can be synthesized later on into a story. But it’s on us to craft a narrative around that that’s actually useful to other people. And that may or may not be a linear narrative. Like with Git, you could take those commits. You can rearrange them. You can squash them. You can split them up however you want. And you can even rewrite history. You can do it out of order. And so, the narratives that we craft with our lives that we craft when we communicate to other people, they may not be linear and that’s okay.

As I said, stories don’t have to have a concrete beginning, a middle, an end, with a climax and a conclusion. They just have to have some sort of a connecting theme and some way, some sort of, for lack of a word, flow or progression, between all those. I hate the word progression because it implies that we’re progressing towards a known outcome. But it just has to have some sort of connections between all of them. And so, I love using Git as an example there because Git as you said, it can be a really useful teaching mechanism for that exact reason. You’re conveying… you’re taking something that may have been very scattered for you. I don’t know how it is for you, but at least for me the process of writing code is not necessarily linear. I don’t know exactly how I want to solve a problem.

SAM:  No.

ADITYA:  Right. If that’s how it is for you, I’m sure we’re hiring, we could probably use someone who knows exactly what they need to write and never makes any mistakes along the way. But…

JAMEY:  We’re also hiring.

ADITYA:  Yeah, right?

JAMEY:  [Laughs]

SAM:  Yeah, but that person is going to be no fun to work with.

ADITYA:  Yeah, and that’s the thing. That’s the thing, is that I say that as a joke, but you’re right. I wouldn’t want to work with that person, because that person wouldn’t have the ability to take a rather messy points of data, here are all the many different commits or attempts that we did over time, and here’s how we actually are going to come up with a solution. The coming up with a solution part, that’s the story that you’re telling. And you don’t highlight all aspects of data in the story the same way in a book, you don’t read every single detail of their lives. The author is choosing which parts are actually going to be relevant.

Storytelling is not just a way to add emotion in the place of data where data doesn’t exist. It’s the way to actually take that data and make it relevant and accessible to people when they need it to be accessible, which is at the end of the day, why we’re trying to do any of this in the first place. What is machine learning but trying to take data and make it accessible to people? Maybe if we actually thought about machine learning and algorithmic decision-making as the process of telling a story, using computers to tell a story, we might end up with a different of paradigms for machine learning.

JAMEY:  I almost want to take this storytelling thing a little bit farther when you were talking about the way people think that emotion is the opposite of empirical data and rationality. And the way I see it, it’s not just not the opposite but it’s almost, you have to blend them into one if you’re going to actually get something that’s true.


JAMEY:  Because when I was listening to Sam’s story about his code and solving problems, I was thinking about taking into consideration the emotional state that somebody was in. If I’m writing a piece of code and I’m feeling very anxious about it, this is something I struggle with because I have anxiety disorder… and sometimes I’ll be like “I know how to write this. I know what I’m doing. It’s not that I’m writing code that doesn’t work,” but because I feel so anxious about this piece of code, sometimes because I’ve been working on it for a long time, that affects how I’m thinking about it. And it affects how I’m working. And so, sometimes the answer really is, looking back on it, why is this like this? And it’s like “Oh, it’s like this because Jamey was feeling anxious while they were writing it.” If you can’t take that information about how I was feeling and integrate it into how you’re thinking about this piece of code, you’re really not getting the full story about it.

ADITYA:  Yeah. There’s a way that you could look at this and say that if you look at open source projects, how much of open source project work actually happens in the repository itself? The larger the project and the more important the project, the less and less that is. If you look at a very large project like the Go programming language or Kubernetes or the Linux kernel…

JAMEY:  Npm.

ADITYA:  Yeah. And so much of the work that makes those projects happen happens on mailing list, on IRC, on Slack channels, in Twitter conversations, and in-person meetups or interactions, in conferences. And those are all part of the story. And it’s easy to say “Well yeah, the code that’s shipped is the stuff that matters,” but that’s just the tip of the iceberg. At that scale, you wouldn’t get all of that code, you wouldn’t get all those great contributions if you don’t have all of that supporting work that contributes to it. And as you said, once we start looking at all of that work as a part of the project itself, as you said, taking into account things like “What are the mental or emotional states of the people who are writing it at that time?” or “What’s the purpose? What’s the subtext of this pull request? Why is this actually being submitted?” Sure, we can analyze it and see what it does, but why is the person submitting it? Is it because they’re really frustrated with this one error message and they’re just writing this as a political move to bypass some other component of the system that they don’t like? Are they doing it because they’re very excited about these other things that it will leverage?

SAM:  And if the person who had written that pull request had been able to tell the story of why they were doing it, you wouldn’t have to try to reconstruct that story in your own head, right?

ADITYA:  Exactly. And conversely, a lot of the most powerful or important discussions we have in open source development are the ones where people actually do include those in their pull request. This is case-dependent. Not every pull request needs a very long story. But particularly for larger, more important features, it’s oftentimes, in my experience those have been… people have had the most success in getting people on board with large technical migrations or large technical changes when they’re able to present that story in that historical context as a part of the decision-making process as opposed to just the thing that led up to it, or stuff that happened in the past.

One thing I would add is that we’ve been talking a lot about storytelling and why it’s important. For anyone who’s listening to this and thinking well, I’m not very good at storytelling. How do I actually develop this as a skill or integrate this into my life? There are two pieces of good news I have. One is that I’m saying that storytelling is something that I think of that’s very important but at the same time, it’s not something I have professional training or experience with. This is something that I just noticed over the course of my life and my career that it’s been a very powerful and important and relevant skill. So, it’s not something that you need to be professionally trained in, in any way, in order to make this skill useful in your daily life. It’s just a general skill, a general pattern. And observe yourself and the opportunities you have to craft narratives in your written or spoken communication, for work or just personal life.

The other useful recommendation I have is regarding public speaking as a particular skill. Storytelling and public speaking are not the same thing. They draw on a lot of the same underlying skills. And the ability to do an effective talk, like deliver an effective conference presentation, is very related to the same skills needed to tell an effective story. The difference really is entirely in how rehearsed or how prepared. It’s the context. And this is something I’ve actually, I’ve done a number of technical talks, not just on technical matters but also on training people, like how to give a technical talk. And this is basically the core of that, which is practice storytelling. Practice it in your daily lives. Practice it in your written communication, because that will help you learn to articulate your thoughts on paper in the same ways that you would need to do it verbally and orally to deliver a talk.

And for public speaking in particular, there are a lot of great opportunities out there. I live in New York which obviously is the center of theater and performing arts. But even in other places, if you live in smaller cities or not near a city, there’s a good chance that you live near some sort of, if not a performing arts school, like a community college or basically any place where you have a lot of people who have backgrounds in acting or theater or performance arts in general. You’ll probably find good classes or workshops, whether that’s improv workshops or actual public speaking classes or anything along those lines. They’ll all help you develop the same adjacent skills to storytelling.

A lot of it is really just though the frame of mind. It’s not so much that you take improv classes to learn how to react quickly in situations and how does that actually apply to storytelling? No. It’s that it trains your mind. It’s cross-training. Like if you go to the gym. You’re cross-training. You’re learning how to be more aware of the ways in which individual dots connect into a larger narrative. And you’re just training yourself to start to recognize those patters and craft those patterns on a higher level.

SAM:  Well unfortunately, we have reached the part of the show where we have to get ready to say goodbye. But first, we get to have some reflections. This is anything that we thought was particularly interesting or can be a call to action or anything that our listeners might take away from this or just that we’re going to take away from this. And for me, I really liked the talk about storytelling the most at the end. It’s a really useful reminder for me to be a little bit more aware of how I can tell a story. Because I do, I think I do some of this instinctively but I could be a lot more explicit about how I tell my stories in my code and in my emails and my chatrooms and everything else that I feel I could be a lot more effective if I actually focused on that a little bit. So, thank you very much. I appreciate that.

ADITYA: Sure thing. For me as well, that conversation is also the most striking. And I really loved the comment that you made. I’m so glad that you used the example specifically of Git commits and how you presented a pull request, because it made me think of in that code review. If you look at it, if you look at pull requests as a story that you’re telling about the code, code review is a chance for the reviewer to be an editor, like an editor of that story.

SAM:  Yeah.

ADITYA: And I know code review is something that a lot of people, there are a lot of different takes on it. A lot of people I think have trouble with it or a lot of people have different opinions on how to tackle it because it’s a hard problem. And I really like the paradigm of thinking of yourself as an editor for the story that you’re adding to this longer epic that’s your project. I’m going to start doing that with my code reviews.

JAMEY:  I want to talk about something that we discussed earlier in the show about machine learning and how you mentioned that the reason that we haven’t figured out all of the solutions, like all of these machine learning problems that we talked about, is because they’re really hard. And that was striking to me because I’ve been thinking a lot about some of the same kind of ethical conundrums in what we do as developers. And one of the questions that has been in the forefront of my mind is the difference between “Can we build this?” versus “Should we build this?” I’ve been kind of thinking about that in terms of as developers we really like solving problems, like interesting problems and difficult problems. And I think there’s a risk of getting so caught up that we forget to think about what we’re doing and hopefully not building stuff that’s awful and terrible. And so, I like thinking about this from the opposite perspective that I have recently. Like you’re saying doing the right thing is like a hard problem. And I kind of like looking at it that way because we like hard problems.

SAM:  Right?

JAMEY:  So, we should be doing this. Why would it being a hard problem stop us from doing it? That should make us excited about it. And it kind of makes me excited about it. And so, I think that’s a good perspective.

ADITYA:  Yeah, I love that. It’s a great way to frame that as a challenge, in language that Silicon Valley really does understand. Because I do think that this is a very actionable problem. We just need to commit ourselves to taking it on.

JAMEY:  Awesome.

SAM:  Well, [inaudible] Jamey. Thank you both very much for participating in this conversation. I had a lot of fun. I learned a bunch of stuff.

For our listeners, I just want to give you a quick reminder that we are in fact a listener-supported show. So, please do your thing at Patreon.com/GreaterThanCode.


This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode.

To make a one-time donation so that we can continue to bring you more content like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.