We Are 3000 Years Behind: Let's Talk About Engineering Ethics
Denbraver, Hayley
Your apartment building where you wake up. The water you drink. The car you drive. The road on which you drive. In the first hour of your day, you rely on the work of several distinct branches of engineering, whose practitioners are licensed and accountable to the public. In the second hour of your day, you may sit down at your desk to write code that dozens, hundreds, thousands, millions of people interact with in some way–but what do they know about you, your intentions, and your training? A licensed Civil Engineer turned software developer will talk through how her former field approached ethics–something they have been iterating on for more than 3000 years. She will discuss how lessons learned from other engineering professions could apply to software, and where our industry may need a new approach to ethics.
 I'm really happy so many of you came out to be lectured at 5 p.m. It's only a little preachy, just a little. Anyway, my name is Hailey Dunbraver and my talk is ominously called We Are 3,000 Years Behind Let's Talk About Engineering Ethics. And here's some of my contact info. My name's Hailey Dunbraver. You can tweet at me there if you're nice. I'm a software developer. I work for a Django shop here in San Diego. And I'm an aspiring developer advocate. Now, engineering ethics, it's kind of funny. I feel like I looked into this topic. It's been really popular on the conference circuit recently. And this is actually the fifth time I've given this talk. So you guys get the best version, I'm hoping. And I've kind of thought about why conference organizers really want to see these talks. And my conclusion was that there has been so much news recently. You can't really ignore it just like these newsies throwing newspapers in your face. And we've had to engage with these maybe scariest stories about Code Gone Wrong that this is just a topic that the people organizing conferences want the community to engage in. So what are some of these stories? Well, they range in severity. They touch a number of different industries. They can range from anything to election meddling to there was a story recently about Wells Fargo. They had some kind of software bug and they foreclosed on a bunch of people's homes without the proper review. And that's kind of scary. And so is the other story. But it seems like every week, and every time I give this talk, there's another anecdote I could add to this list. So it seems like all the time we're being confronted with ways that software can go wrong. And I want us to just take a little bit of time to think about what we do and how we might approach it in a better way. So I made a big diagram. It's really exciting. This is how I think about my work and how it could go wrong. Now the red circle are bad outcomes. So this is anything that causes some kind of loss of failure, some kind of pain suffering. Bad thing. And I could be immoral and that would fall in the yellow circle. And these are the sort of things that Jiminy Cricket, the little cricket on your shoulder, your conscience would kind of give you a bad feeling about. Like bribery, cutting corners to skim money off the top. You know, I don't know. Something kind of nasty like that. And this blue circle mistakes would be something that has zero malice, but we're human. And so sometimes our code isn't perfect. And I would argue that all the time our code isn't perfect. But some of the time when we behave badly or when we make mistakes, there's overlaps with this bad outcome. And I specifically want to talk about these overlaps because these are the areas that I want to minimize. And these are the areas that my previous profession sought to minimize. So what did I use to do? Well, I used to be a structural design engineer. I was a licensed civil engineer. And I did all sorts of work. Some of it was kind of boring. I anchored this AC to the top of a hospital. And that was the fun one. And then the hotel near Disneyland, that was the boring one, or maybe it was the other way around. But the hotel near Disneyland really was my favorite. But these are a wide variety of jobs. And I was responsible to the public for both of these things. And I want to kind of dive into that a little bit. Now my former profession was really, really old. These are old examples of engineering. They're also a little more interesting than an AC unit on top of a hotel, or a hospital, rather. And more than 3,000 years ago, we, as civil engineers, got our first taste of what it's like to be under some regulation by the state. And this was the form of Code of Hammurabi. Now this was a king in Babylonia more than 3,000 years ago. And we're going to read some of his laws. And they are kind of harsh just to warn you. So here's the Codex. And here is a kind of graphic picture. It's to prepare you for the graphic law that we're going to read. Most of the Code of Hammurabi is this grizzly, if then, statements kind of things. And you might better know that form as an I for an I. So we call this the law of retribution. So let's dive into the laws. If a builder builds a house for someone and completes it, he shall give him a fee of two shekels in money for each sorrow surface. So this is like a refund for like small defects in your work. Okay, I'm okay with this. 229, if a builder builds a house for someone and does not construct it properly and the house which he built falls in and kills its owner, then that builder shall be put to death. A little less okay with that one. If it kills the son of the owner, the son of the builder shall be put to death, WTF. Okay, no, no, no. The kills the slave of the owner, then he shall pay slave for slave to the owner of the house. If it ruins goods, he shall make compensation for all that has been ruined. And in as much as he did not construct it properly, this house he built and it fell, he shall re- erect the house from his own means. We're back to somewhat reasonable. Okay, if a builder builds a house for someone, even though he has not yet completed it, if then the walls seem toppling, the builder must make the wall solid from his own means. So this law meant that an engineer was responsible even on to loss or death. And this is the point in the talk where I have a long dramatic pause and I wasn't super comfortable with that. So I put a GIF in and this GIF is Rory explained to Paris about dramatic pauses. So we're going to look at that and then we're going to dramatic pause again. So an engineer was responsible even on to loss or death. Now that was an old law and I want to take us a little bit more into the present but not too far and we're going to talk about something that happened in 1919. And I don't know if you've heard the saying that tragedy plus time equals comedy but we're going to hope that that's true because I tried to pick the funniest story I could. It's kind of, I mean it's a disaster. So it's hard but we're going to roll with that. And we're going to talk about the 1919 Boston molasses flood. All right, so in January of 1919 a tank failed in a neighborhood in Boston and the structural defect with the pressure of the tank and millions of gallons of molasses flooded the area. It toppled a train track, an elevated train track and just spilled all over the neighborhood. It was pretty terrible and this says that it killed 11 but eventually it was 21. So this was really, really bad and people were really, really mad and they had a trial and eventually it was decided that we needed some licensure for engineers. So we had moved from an eye for an eye of Hammurabi to a system of licensure which you could also call gate keeping. So no longer eye for eye but Gretchen saying you can't sit with us. Now this is the current department that regulates practice of civil engineering and the reason that they license individuals is to restrict practice to people who have proven themselves through their educational credits, test taking and work experience to be capable of doing these sorts of jobs. So licensure is a system of formalized responsibility and I want to be clear this isn't the same as ethics but taking responsibility for your work is a pretty good start. So I just want to talk about it. I'm going to do that through montage. We're going to explore what it took for me to get my license. So what you have to do is you have to start with dramatic music because it's a montage and that's what happens. So something like... And then I graduated from an accredited university and it was exciting and I didn't throw my hat to anybody for their hat but yeah this was me undergrad. Then I did some one handed push ups because I was 22. Then I went to grad school because it was 2009 and no one wanted to hire anybody and I also learned that I didn't know how to study yet. But I figured that out and I passed grad school and then I took a well deserved dance break and then I worked for several years and hopefully was more competent than Homer Simpson and then I took up running because it was kind of stressful. That point I had to go door to door or rather cubicle to cubicle to all my coworkers and get them to vouch for me and I was really lucky because none of them looked at me like Lucille is looking at us right now. Then I had another dance break because Carlton is amazing and then I had to take a three day exam that cost more than $1,000 and almost broke my will to live. And fortunately I passed the first time because that was really expensive and seen and a montage. Thank you for tolerating my gifts. I appreciate that. Now, like I said, licensure is a system of formalized responsibility. None of this montage means that I was moral or good but it meant that I had kind of cleared a background check and it also meant that I had been tested on and had been exposed to ethical practice ideas through my education and through my testing. So I promised to talk about code. We're going to do that right now. Because that's why we're here. Code. Now, I used to be a civil engineer and now I'm a software engineer so what is different about these two careers? Now, I'm going to start it off with kind of a bummer and tell you the unfortunate truth about the title of software engineer. The title of software engineer is largely imaginary. It doesn't mean a whole lot. When I graduated my boot camp, I was issued these business cards and they said, Hailey Dunn Braver software engineer and I kind of looked at them, sited them and went, I don't know about that. And that's because civil engineer is a title that has to be earned and any of you would get into trouble if you printed business cards with civil engineer on it. Just like I would get into trouble if I printed a card that said Hailey Dunn Braver MD and tried to treat patients. Like you can't do that. It's a protected title. At least in America, software engineer is not. So that's the unfortunate truth. It might mean something to your organization, to your career trajectory, but it doesn't mean anything in terms of our responsibility to the public or what the public can expect from us. Another difference in my time as a software engineer is the diversity background of myself and of my team. Show of hands who here has a BS in computer science. Okay, so that's not zero, but that is maybe about 50%. It looked like. So where I work, we have some compsci degree holders. We have some self-taught people. We have some people like me who went to a boot camp. And we have some internally trained devs that came up through a program that we have where I work. And this diversity of background would make no sense in a civil engineering office. So that was a really big difference. What's another difference? These are the varied and awesome gophers that write go code. I wanted pythons, but the gophers are really cute. So that's what we went. So what's another difference? There's a difference in how the work is evaluated. Pushing to GitHub and opening PRs and reviewing code is absolutely necessary. Please do that. But it isn't the same thing as taking structural plans and structural calculations to a governing body and getting them approved and then they're on file forever and can be brought up years and years later. It's just not the same thing. There's another difference. Oh, that's the only difference I had. Well, okay. So these two careers, they're different, but they're different careers. So why would you expect them to be the same? I'm following you, but so what? Right? Well, it's okay to not know what you're doing all the time. All right? Sometimes we write code that isn't going to hurt anybody. I personally think that none of you has written code that has drowned anyone in molasses. I know I haven't. So if you feel like this dog ever, that's okay. He's a good boy. He would never hurt anybody. And we do have some rules with respect to how we operate. There are rules about private information. There's rules about health data. So it's not like we're in the Wild West or a dystopian novel or anything like that, right? But remember those news stories from before. You don't really know the future, but it's possible that we're going to have to wrestle with these ideas and engage with them in a meaningful way at some point, right? And I have some limited answers on how we could possibly do that. It's just a start. Imagine we're in the first Bowser castle. So our princess isn't in this castle. She's in another castle, but you have to start somewhere. So we're going to start in this first castle. These are my recommendations. Number one, promote ethical literacy. All of you are professionals, and we're expected to maintain our technical literacy. And as professionals, ethical literacy is important too. It's a skill that doctors have. It's a skill that lawyers have. Any other profession deals with these concepts. So I want that to be the industry standard. A good place for you to start would be to Google ACM's code of ethics. And that's where you can begin your learning on this topic. Now, second thing I'd like to see is I would like to see review taken more seriously. There was a really good talk earlier in the conference about code review skills for Pythonistas. And Nina mentioned that the level or like the impact of your code is going to be at different levels, and that would require different sorts of review. And I'm trying to make a similar point. Maybe you do some rubber stamping. Maybe you should stop that. And maybe you should take a look at the potential impact of the particular code that you're pushing and review it with that in mind. And I would even say that for something that is extremely important and has the potential to harm others, I would recommend getting some outside help even. If it's that serious, bring someone else in, get some fresh eyes, and take review more seriously in general. Senior should mean something. What I mean by this is that we may have a diversity of background, but we could have am I okay? Okay, that's perfect. So seniors should mean something, and by that I mean that while we have a diversity of background, we could have a commonality of mentorship and professional engagement within our teams to really grow as professionals and learn from people who have established good practices prior to now. And this helps with the previous two points I mentioned, taking review more seriously, and promoting ethical literacy. Seniors can lead the way with that. Now fourth, I want to improve communication. Now when I was a civil engineer, I had veto power, and it was amazing if someone was doing something dumb, I could be like, nope, sorry, redo that. No, no, no, no. I don't really have that power now, and I don't know if it's really necessary, but what I do know is I have a lot of people that I work with, and in order to be ethical and to build products that are going to be good for the community, I need to be able to communicate well with them and be able to raise concerns if and when I have them. So improving communication is my fourth suggestion. My fifth and final suggestion is to pretend that you're licensed and really, really, just try this, it's kind of weird, but good. Now I actually did this as a civil engineer. Before I got licensed, I had to act licensed. My coworkers had to stamp my work because they needed to be stamped by a professional engineer. And what that meant is I had to approach my work as though I would stamp it, right, because it's unfair to ask someone to put their name on your work if you would not be willing to put your name on your work, right? So pretend like you are bound to some professional code and act accordingly. Imagine that Git blame is like carved into stone and that you're accountable for what you write. So promoting ethical literacy, taking your view more seriously, senior should mean something, proving communication, and pretending you're licensed. Now in the last few seconds, I'm going to revisit the molasses flood. Lunge people died in molasses, really terrible, terrible, terrible. Hundred years before that, there was something called the London beer flood, which is, yeah, it was pretty similar. A few million gallons of beer spilled and it killed eight people and maybe a ninth from alcohol poisoning. It's not really clear. And the neighborhood was really mad and they held a trial and the result was that it was an act of God. Now I ask you, why do you think that engineers haven't been really held as accountable as maybe they should? And I would argue that it's because to a large portion of the community, what we do is kind of magic and if you don't understand something, it's easy to just accept it and to not be able to demand accountability. So we don't use this language, but it's a similar thought. So the molasses flood was different and I would argue that it's because people had to walk around in their sticky neighborhood and sit on their sticky train seats and they had basically landed in the molasses swamp in Candyland and they're stuck there and it's not fun. And when you can't forget something, when you can't forget something, you have to engage with it and that's what brought about change. So may this stick with you, when you walk into your job on Thursday or Monday or whatever, maybe your shoes are kind of sticking to the ground and you reach for your keyboard and it's kind of gross and you can really forget that. And don't forget this either. You build products for people and they deserve your attention and your care, your consideration and it's okay to have a little molasses if that helps you remember it. So thank you all. This is my contact info, Hailey Denby on Twitter and thank you very, very much. Thank you.
 I'm really happy so many of you came out to be lectured at 5 p.m.  It's only a little preachy, just a little.  Anyway, my name is Hailey Dunbraver and my talk is ominously called We Are 3,000 Years  Behind Let's Talk About Engineering Ethics.  And here's some of my contact info.  My name's Hailey Dunbraver.  You can tweet at me there if you're nice.  I'm a software developer.  I work for a Django shop here in San Diego.  And I'm an aspiring developer advocate.  Now, engineering ethics, it's kind of funny.  I feel like I looked into this topic.  It's been really popular on the conference circuit recently.  And this is actually the fifth time I've given this talk.  So you guys get the best version, I'm hoping.  And I've kind of thought about why conference organizers really want to see these talks.  And my conclusion was that there has been so much news recently.  You can't really ignore it just like these newsies throwing newspapers in your face.  And we've had to engage with these maybe scariest stories about Code Gone Wrong that this is  just a topic that the people organizing conferences want the community to engage in.  So what are some of these stories?  Well, they range in severity.  They touch a number of different industries.  They can range from anything to election meddling to there was a story recently about Wells  Fargo.  They had some kind of software bug and they foreclosed on a bunch of people's homes without  the proper review.  And that's kind of scary.  And so is the other story.  But it seems like every week, and every time I give this talk, there's another anecdote  I could add to this list.  So it seems like all the time we're being confronted with ways that software can go wrong.  And I want us to just take a little bit of time to think about what we do and how we  might approach it in a better way.  So I made a big diagram.  It's really exciting.  This is how I think about my work and how it could go wrong.  Now the red circle are bad outcomes.  So this is anything that causes some kind of loss of failure, some kind of pain suffering.  Bad thing.  And I could be immoral and that would fall in the yellow circle.  And these are the sort of things that Jiminy Cricket, the little cricket on your shoulder,  your conscience would kind of give you a bad feeling about.  Like bribery, cutting corners to skim money off the top.  You know, I don't know.  Something kind of nasty like that.  And this blue circle mistakes would be something that has zero malice, but we're human.  And so sometimes our code isn't perfect.  And I would argue that all the time our code isn't perfect.  But some of the time when we behave badly or when we make mistakes, there's overlaps  with this bad outcome.  And I specifically want to talk about these overlaps because these are the areas that  I want to minimize.  And these are the areas that my previous profession sought to minimize.  So what did I use to do?  Well, I used to be a structural design engineer.  I was a licensed civil engineer.  And I did all sorts of work.  Some of it was kind of boring.  I anchored this AC to the top of a hospital.  And that was the fun one.  And then the hotel near Disneyland, that was the boring one, or maybe it was the other  way around.  But the hotel near Disneyland really was my favorite.  But these are a wide variety of jobs.  And I was responsible to the public for both of these things.  And I want to kind of dive into that a little bit.  Now my former profession was really, really old.  These are old examples of engineering.  They're also a little more interesting than an AC unit on top of a hotel, or a hospital,  rather.  And more than 3,000 years ago, we, as civil engineers, got our first taste of what it's  like to be under some regulation by the state.  And this was the form of Code of Hammurabi.  Now this was a king in Babylonia more than 3,000 years ago.  And we're going to read some of his laws.  And they are kind of harsh just to warn you.  So here's the Codex.  And here is a kind of graphic picture.  It's to prepare you for the graphic law that we're going to read.  Most of the Code of Hammurabi is this grizzly, if then, statements kind of things.  And you might better know that form as an I for an I.  So we call this the law of retribution.  So let's dive into the laws.  If a builder builds a house for someone and completes it, he shall give him a fee of two  shekels in money for each sorrow surface.  So this is like a refund for like small defects in your work.  Okay, I'm okay with this.  229, if a builder builds a house for someone and does not construct it properly and the  house which he built falls in and kills its owner, then that builder shall be put to death.  A little less okay with that one.  If it kills the son of the owner, the son of the builder shall be put to death, WTF.  Okay, no, no, no.  The kills the slave of the owner, then he shall pay slave for slave to the owner of the  house.  If it ruins goods, he shall make compensation for all that has been ruined.  And in as much as he did not construct it properly, this house he built and it fell,  he shall re- erect the house from his own means.  We're back to somewhat reasonable.  Okay, if a builder builds a house for someone, even though he has not yet completed it, if  then the walls seem toppling, the builder must make the wall solid from his own means.  So this law meant that an engineer was responsible even on to loss or death.  And this is the point in the talk where I have a long dramatic pause and I wasn't super  comfortable with that.  So I put a GIF in and this GIF is Rory explained to Paris about dramatic pauses.  So we're going to look at that and then we're going to dramatic pause again.  So an engineer was responsible even on to loss or death.  Now that was an old law and I want to take us a little bit more into the present but  not too far and we're going to talk about something that happened in 1919.  And I don't know if you've heard the saying that tragedy plus time equals comedy but we're  going to hope that that's true because I tried to pick the funniest story I could.  It's kind of, I mean it's a disaster.  So it's hard but we're going to roll with that.  And we're going to talk about the 1919 Boston molasses flood.  All right, so in January of 1919 a tank failed in a neighborhood in Boston and the structural  defect with the pressure of the tank and millions of gallons of molasses flooded the area.  It toppled a train track, an elevated train track and just spilled all over the neighborhood.  It was pretty terrible and this says that it killed 11 but eventually it was 21.  So this was really, really bad and people were really, really mad and they had a trial  and eventually it was decided that we needed some licensure for engineers.  So we had moved from an eye for an eye of Hammurabi to a system of licensure which you  could also call gate keeping.  So no longer eye for eye but Gretchen saying you can't sit with us.  Now this is the current department that regulates practice of civil engineering and the reason  that they license individuals is to restrict practice to people who have proven themselves  through their educational credits, test taking and work experience to be capable of doing  these sorts of jobs.  So licensure is a system of formalized responsibility and I want to be clear this isn't the same  as ethics but taking responsibility for your work is a pretty good start.  So I just want to talk about it.  I'm going to do that through montage.  We're going to explore what it took for me to get my license.  So what you have to do is you have to start with dramatic music because it's a montage  and that's what happens.  So something like...  And then I graduated from an accredited university and it was exciting and I didn't  throw my hat to anybody for their hat but yeah this was me undergrad.  Then I did some one handed push ups because I was 22.  Then I went to grad school because it was 2009 and no one wanted to hire anybody and  I also learned that I didn't know how to study yet.  But I figured that out and I passed grad school and then I took a well deserved dance break  and then I worked for several years and hopefully was more competent than Homer Simpson and then  I took up running because it was kind of stressful.  That point I had to go door to door or rather cubicle to cubicle to all my coworkers and  get them to vouch for me and I was really lucky because none of them looked at me like Lucille  is looking at us right now.  Then I had another dance break because Carlton is amazing and then I had to take a three  day exam that cost more than $1,000 and almost broke my will to live.  And fortunately I passed the first time because that was really expensive and seen and a montage.  Thank you for tolerating my gifts.  I appreciate that.  Now, like I said, licensure is a system of formalized responsibility.  None of this montage means that I was moral or good but it meant that I had kind of cleared  a background check and it also meant that I had been tested on and had been exposed  to ethical practice ideas through my education and through my testing.  So I promised to talk about code.  We're going to do that right now.  Because that's why we're here.  Code.  Now, I used to be a civil engineer and now I'm a software engineer so what is different  about these two careers?  Now, I'm going to start it off with kind of a bummer and tell you the unfortunate truth  about the title of software engineer.  The title of software engineer is largely imaginary.  It doesn't mean a whole lot.  When I graduated my boot camp, I was issued these business cards and they said, Hailey  Dunn Braver software engineer and I kind of looked at them, sited them and went, I don't  know about that.  And that's because civil engineer is a title that has to be earned and any of you would  get into trouble if you printed business cards with civil engineer on it.  Just like I would get into trouble if I printed a card that said Hailey Dunn Braver MD and  tried to treat patients.  Like you can't do that.  It's a protected title.  At least in America, software engineer is not.  So that's the unfortunate truth.  It might mean something to your organization, to your career trajectory, but it doesn't  mean anything in terms of our responsibility to the public or what the public can expect  from us.  Another difference in my time as a software engineer is the diversity background of myself  and of my team.  Show of hands who here has a BS in computer science.  Okay, so that's not zero, but that is maybe about 50%.  It looked like.  So where I work, we have some compsci degree holders.  We have some self-taught people.  We have some people like me who went to a boot camp.  And we have some internally trained devs that came up through a program that we have where  I work.  And this diversity of background would make no sense in a civil engineering office.  So that was a really big difference.  What's another difference?  These are the varied and awesome gophers that write go code.  I wanted pythons, but the gophers are really cute.  So that's what we went.  So what's another difference?  There's a difference in how the work is evaluated.  Pushing to GitHub and opening PRs and reviewing code is absolutely necessary.  Please do that.  But it isn't the same thing as taking structural plans and structural calculations to a governing  body and getting them approved and then they're on file forever and can be brought up years  and years later.  It's just not the same thing.  There's another difference.  Oh, that's the only difference I had.  Well, okay.  So these two careers, they're different, but they're different careers.  So why would you expect them to be the same?  I'm following you, but so what?  Right?  Well, it's okay to not know what you're doing all the time.  All right?  Sometimes we write code that isn't going to hurt anybody.  I personally think that none of you has written code that has drowned anyone in molasses.  I know I haven't.  So if you feel like this dog ever, that's okay.  He's a good boy.  He would never hurt anybody.  And we do have some rules with respect to how we operate.  There are rules about private information.  There's rules about health data.  So it's not like we're in the Wild West or a dystopian novel or anything like that, right?  But remember those news stories from before.  You don't really know the future, but it's possible that we're going to have to wrestle  with these ideas and engage with them in a meaningful way at some point, right?  And I have some limited answers on how we could possibly do that.  It's just a start.  Imagine we're in the first Bowser castle.  So our princess isn't in this castle.  She's in another castle, but you have to start somewhere.  So we're going to start in this first castle.  These are my recommendations.  Number one, promote ethical literacy.  All of you are professionals, and we're expected to maintain our technical literacy.  And as professionals, ethical literacy is important too.  It's a skill that doctors have.  It's a skill that lawyers have.  Any other profession deals with these concepts.  So I want that to be the industry standard.  A good place for you to start would be to Google ACM's code of ethics.  And that's where you can begin your learning on this topic.  Now, second thing I'd like to see is I would like to see review taken more seriously.  There was a really good talk earlier in the conference about code review skills for Pythonistas.  And Nina mentioned that the level or like the impact of your code is going to be at  different levels, and that would require different sorts of review.  And I'm trying to make a similar point.  Maybe you do some rubber stamping.  Maybe you should stop that.  And maybe you should take a look at the potential impact of the particular code that you're  pushing and review it with that in mind.  And I would even say that for something that is extremely important and has the potential  to harm others, I would recommend getting some outside help even.  If it's that serious, bring someone else in, get some fresh eyes, and take review more  seriously in general.  Senior should mean something.  What I mean by this is that we may have a diversity of background, but we could have  am I okay?  Okay, that's perfect.  So seniors should mean something, and by that I mean that while we have a diversity of background,  we could have a commonality of mentorship and professional engagement within our teams  to really grow as professionals and learn from people who have established good practices  prior to now.  And this helps with the previous two points I mentioned, taking review more seriously,  and promoting ethical literacy.  Seniors can lead the way with that.  Now fourth, I want to improve communication.  Now when I was a civil engineer, I had veto power, and it was amazing if someone was doing  something dumb, I could be like, nope, sorry, redo that.  No, no, no, no.  I don't really have that power now, and I don't know if it's really necessary, but  what I do know is I have a lot of people that I work with, and in order to be ethical and  to build products that are going to be good for the community, I need to be able to communicate  well with them and be able to raise concerns if and when I have them.  So improving communication is my fourth suggestion.  My fifth and final suggestion is to pretend that you're licensed and really, really, just  try this, it's kind of weird, but good.  Now I actually did this as a civil engineer.  Before I got licensed, I had to act licensed.  My coworkers had to stamp my work because they needed to be stamped by a professional  engineer.  And what that meant is I had to approach my work as though I would stamp it, right, because  it's unfair to ask someone to put their name on your work if you would not be willing to  put your name on your work, right?  So pretend like you are bound to some professional code and act accordingly.  Imagine that Git blame is like carved into stone and that you're accountable for what  you write.  So promoting ethical literacy, taking your view more seriously, senior should mean something,  proving communication, and pretending you're licensed.  Now in the last few seconds, I'm going to revisit the molasses flood.  Lunge people died in molasses, really terrible, terrible, terrible.  Hundred years before that, there was something called the London beer flood, which is, yeah,  it was pretty similar.  A few million gallons of beer spilled and it killed eight people and maybe a ninth from  alcohol poisoning.  It's not really clear.  And the neighborhood was really mad and they held a trial and the result was that it was  an act of God.  Now I ask you, why do you think that engineers haven't been really held as accountable as  maybe they should?  And I would argue that it's because to a large portion of the community, what we do is kind  of magic and if you don't understand something, it's easy to just accept it and to not be  able to demand accountability.  So we don't use this language, but it's a similar thought.  So the molasses flood was different and I would argue that it's because people had to  walk around in their sticky neighborhood and sit on their sticky train seats and they had  basically landed in the molasses swamp in Candyland and they're stuck there and it's  not fun.  And when you can't forget something, when you can't forget something, you have to engage  with it and that's what brought about change.  So may this stick with you, when you walk into your job on Thursday or Monday or whatever,  maybe your shoes are kind of sticking to the ground and you reach for your keyboard and  it's kind of gross and you can really forget that.  And don't forget this either.  You build products for people and they deserve your attention and your care, your consideration  and it's okay to have a little molasses if that helps you remember it.  So thank you all.  This is my contact info, Hailey Denby on Twitter and thank you very, very much.  Thank you.
DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_0_335.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_336_4307.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_4308_8435.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_8436_9923.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_9924_12419.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_12420_14819.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_14820_15251.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_15252_17039.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_17040_17567.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_17568_17747.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_17748_17855.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_17856_18107.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_18108_18155.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_18156_19535.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_19536_19991.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_19992_24899.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_24900_27299.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_27300_34511.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_34512_35423.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_35424_38447.png DjangoCon_US_2018_-_We_Are_3000_Years_Behind____by_Hayley_Denbraver_Rg3v3dzqa2o_38448_38564.png
I'm really happy so many of you came out to be lectured at 5 p.m. It's only a little preachy, just a little. Anyway, my name is Hailey Dunbraver and my talk is ominously called We Are 3,000 Years Behind Let's Talk About Engineering Ethics. And here's some of my contact info. My name's Hailey Dunbraver. You can tweet at me there if you're nice. I'm a software developer. I work for a Django shop here in San Diego. And I'm an aspiring developer advocate. Now, engineering ethics, it's kind of funny. I feel like I looked into this topic. It's been really popular on the conference circuit recently. And this is actually the fifth time I've given this talk. So you guys get the best version, I'm hoping. And I've kind of thought about why conference organizers really want to see these talks. And my conclusion was that there has been so much news recently. You can't really ignore it just like these newsies throwing newspapers in your face. And we've had to engage with these maybe scariest stories about Code Gone Wrong that this is just a topic that the people organizing conferences want the community to engage in. So what are some of these stories? Well, they range in severity. They touch a number of different industries. They can range from anything to election meddling to there was a story recently about Wells Fargo. They had some kind of software bug and they foreclosed on a bunch of people's homes without the proper review. And that's kind of scary. And so is the other story. But it seems like every week, and every time I give this talk, there's another anecdote I could add to this list. So it seems like all the time we're being confronted with ways that software can go wrong. And I want us to just take a little bit of time to think about what we do and how we might approach it in a better way. So I made a big diagram. It's really exciting. This is how I think about my work and how it could go wrong. Now the red circle are bad outcomes. So this is anything that causes some kind of loss of failure, some kind of pain suffering. Bad thing. And I could be immoral and that would fall in the yellow circle. And these are the sort of things that Jiminy Cricket, the little cricket on your shoulder, your conscience would kind of give you a bad feeling about. Like bribery, cutting corners to skim money off the top. You know, I don't know. Something kind of nasty like that. And this blue circle mistakes would be something that has zero malice, but we're human. And so sometimes our code isn't perfect. And I would argue that all the time our code isn't perfect. But some of the time when we behave badly or when we make mistakes, there's overlaps with this bad outcome. And I specifically want to talk about these overlaps because these are the areas that I want to minimize. And these are the areas that my previous profession sought to minimize. So what did I use to do? Well, I used to be a structural design engineer. I was a licensed civil engineer. And I did all sorts of work. Some of it was kind of boring. I anchored this AC to the top of a hospital. And that was the fun one. And then the hotel near Disneyland, that was the boring one, or maybe it was the other way around. But the hotel near Disneyland really was my favorite. But these are a wide variety of jobs. And I was responsible to the public for both of these things. And I want to kind of dive into that a little bit. Now my former profession was really, really old. These are old examples of engineering. They're also a little more interesting than an AC unit on top of a hotel, or a hospital, rather. And more than 3,000 years ago, we, as civil engineers, got our first taste of what it's like to be under some regulation by the state. And this was the form of Code of Hammurabi. Now this was a king in Babylonia more than 3,000 years ago. And we're going to read some of his laws. And they are kind of harsh just to warn you. So here's the Codex. And here is a kind of graphic picture. It's to prepare you for the graphic law that we're going to read. Most of the Code of Hammurabi is this grizzly, if then, statements kind of things. And you might better know that form as an I for an I. So we call this the law of retribution. So let's dive into the laws. If a builder builds a house for someone and completes it, he shall give him a fee of two shekels in money for each sorrow surface. So this is like a refund for like small defects in your work. Okay, I'm okay with this. 229, if a builder builds a house for someone and does not construct it properly and the house which he built falls in and kills its owner, then that builder shall be put to death. A little less okay with that one. If it kills the son of the owner, the son of the builder shall be put to death, WTF. Okay, no, no, no. The kills the slave of the owner, then he shall pay slave for slave to the owner of the house. If it ruins goods, he shall make compensation for all that has been ruined. And in as much as he did not construct it properly, this house he built and it fell, he shall re- erect the house from his own means. We're back to somewhat reasonable. Okay, if a builder builds a house for someone, even though he has not yet completed it, if then the walls seem toppling, the builder must make the wall solid from his own means. So this law meant that an engineer was responsible even on to loss or death. And this is the point in the talk where I have a long dramatic pause and I wasn't super comfortable with that. So I put a GIF in and this GIF is Rory explained to Paris about dramatic pauses. So we're going to look at that and then we're going to dramatic pause again. So an engineer was responsible even on to loss or death. Now that was an old law and I want to take us a little bit more into the present but not too far and we're going to talk about something that happened in 1919. And I don't know if you've heard the saying that tragedy plus time equals comedy but we're going to hope that that's true because I tried to pick the funniest story I could. It's kind of, I mean it's a disaster. So it's hard but we're going to roll with that. And we're going to talk about the 1919 Boston molasses flood. All right, so in January of 1919 a tank failed in a neighborhood in Boston and the structural defect with the pressure of the tank and millions of gallons of molasses flooded the area. It toppled a train track, an elevated train track and just spilled all over the neighborhood. It was pretty terrible and this says that it killed 11 but eventually it was 21. So this was really, really bad and people were really, really mad and they had a trial and eventually it was decided that we needed some licensure for engineers. So we had moved from an eye for an eye of Hammurabi to a system of licensure which you could also call gate keeping. So no longer eye for eye but Gretchen saying you can't sit with us. Now this is the current department that regulates practice of civil engineering and the reason that they license individuals is to restrict practice to people who have proven themselves through their educational credits, test taking and work experience to be capable of doing these sorts of jobs. So licensure is a system of formalized responsibility and I want to be clear this isn't the same as ethics but taking responsibility for your work is a pretty good start. So I just want to talk about it. I'm going to do that through montage. We're going to explore what it took for me to get my license. So what you have to do is you have to start with dramatic music because it's a montage and that's what happens. So something like... And then I graduated from an accredited university and it was exciting and I didn't throw my hat to anybody for their hat but yeah this was me undergrad. Then I did some one handed push ups because I was 22. Then I went to grad school because it was 2009 and no one wanted to hire anybody and I also learned that I didn't know how to study yet. But I figured that out and I passed grad school and then I took a well deserved dance break and then I worked for several years and hopefully was more competent than Homer Simpson and then I took up running because it was kind of stressful. That point I had to go door to door or rather cubicle to cubicle to all my coworkers and get them to vouch for me and I was really lucky because none of them looked at me like Lucille is looking at us right now. Then I had another dance break because Carlton is amazing and then I had to take a three day exam that cost more than $1,000 and almost broke my will to live. And fortunately I passed the first time because that was really expensive and seen and a montage. Thank you for tolerating my gifts. I appreciate that. Now, like I said, licensure is a system of formalized responsibility. None of this montage means that I was moral or good but it meant that I had kind of cleared a background check and it also meant that I had been tested on and had been exposed to ethical practice ideas through my education and through my testing. So I promised to talk about code. We're going to do that right now. Because that's why we're here. Code. Now, I used to be a civil engineer and now I'm a software engineer so what is different about these two careers? Now, I'm going to start it off with kind of a bummer and tell you the unfortunate truth about the title of software engineer. The title of software engineer is largely imaginary. It doesn't mean a whole lot. When I graduated my boot camp, I was issued these business cards and they said, Hailey Dunn Braver software engineer and I kind of looked at them, sited them and went, I don't know about that. And that's because civil engineer is a title that has to be earned and any of you would get into trouble if you printed business cards with civil engineer on it. Just like I would get into trouble if I printed a card that said Hailey Dunn Braver MD and tried to treat patients. Like you can't do that. It's a protected title. At least in America, software engineer is not. So that's the unfortunate truth. It might mean something to your organization, to your career trajectory, but it doesn't mean anything in terms of our responsibility to the public or what the public can expect from us. Another difference in my time as a software engineer is the diversity background of myself and of my team. Show of hands who here has a BS in computer science. Okay, so that's not zero, but that is maybe about 50%. It looked like. So where I work, we have some compsci degree holders. We have some self-taught people. We have some people like me who went to a boot camp. And we have some internally trained devs that came up through a program that we have where I work. And this diversity of background would make no sense in a civil engineering office. So that was a really big difference. What's another difference? These are the varied and awesome gophers that write go code. I wanted pythons, but the gophers are really cute. So that's what we went. So what's another difference? There's a difference in how the work is evaluated. Pushing to GitHub and opening PRs and reviewing code is absolutely necessary. Please do that. But it isn't the same thing as taking structural plans and structural calculations to a governing body and getting them approved and then they're on file forever and can be brought up years and years later. It's just not the same thing. There's another difference. Oh, that's the only difference I had. Well, okay. So these two careers, they're different, but they're different careers. So why would you expect them to be the same? I'm following you, but so what? Right? Well, it's okay to not know what you're doing all the time. All right? Sometimes we write code that isn't going to hurt anybody. I personally think that none of you has written code that has drowned anyone in molasses. I know I haven't. So if you feel like this dog ever, that's okay. He's a good boy. He would never hurt anybody. And we do have some rules with respect to how we operate. There are rules about private information. There's rules about health data. So it's not like we're in the Wild West or a dystopian novel or anything like that, right? But remember those news stories from before. You don't really know the future, but it's possible that we're going to have to wrestle with these ideas and engage with them in a meaningful way at some point, right? And I have some limited answers on how we could possibly do that. It's just a start. Imagine we're in the first Bowser castle. So our princess isn't in this castle. She's in another castle, but you have to start somewhere. So we're going to start in this first castle. These are my recommendations. Number one, promote ethical literacy. All of you are professionals, and we're expected to maintain our technical literacy. And as professionals, ethical literacy is important too. It's a skill that doctors have. It's a skill that lawyers have. Any other profession deals with these concepts. So I want that to be the industry standard. A good place for you to start would be to Google ACM's code of ethics. And that's where you can begin your learning on this topic. Now, second thing I'd like to see is I would like to see review taken more seriously. There was a really good talk earlier in the conference about code review skills for Pythonistas. And Nina mentioned that the level or like the impact of your code is going to be at different levels, and that would require different sorts of review. And I'm trying to make a similar point. Maybe you do some rubber stamping. Maybe you should stop that. And maybe you should take a look at the potential impact of the particular code that you're pushing and review it with that in mind. And I would even say that for something that is extremely important and has the potential to harm others, I would recommend getting some outside help even. If it's that serious, bring someone else in, get some fresh eyes, and take review more seriously in general. Senior should mean something. What I mean by this is that we may have a diversity of background, but we could have am I okay? Okay, that's perfect. So seniors should mean something, and by that I mean that while we have a diversity of background, we could have a commonality of mentorship and professional engagement within our teams to really grow as professionals and learn from people who have established good practices prior to now. And this helps with the previous two points I mentioned, taking review more seriously, and promoting ethical literacy. Seniors can lead the way with that. Now fourth, I want to improve communication. Now when I was a civil engineer, I had veto power, and it was amazing if someone was doing something dumb, I could be like, nope, sorry, redo that. No, no, no, no. I don't really have that power now, and I don't know if it's really necessary, but what I do know is I have a lot of people that I work with, and in order to be ethical and to build products that are going to be good for the community, I need to be able to communicate well with them and be able to raise concerns if and when I have them. So improving communication is my fourth suggestion. My fifth and final suggestion is to pretend that you're licensed and really, really, just try this, it's kind of weird, but good. Now I actually did this as a civil engineer. Before I got licensed, I had to act licensed. My coworkers had to stamp my work because they needed to be stamped by a professional engineer. And what that meant is I had to approach my work as though I would stamp it, right, because it's unfair to ask someone to put their name on your work if you would not be willing to put your name on your work, right? So pretend like you are bound to some professional code and act accordingly. Imagine that Git blame is like carved into stone and that you're accountable for what you write. So promoting ethical literacy, taking your view more seriously, senior should mean something, proving communication, and pretending you're licensed. Now in the last few seconds, I'm going to revisit the molasses flood. Lunge people died in molasses, really terrible, terrible, terrible. Hundred years before that, there was something called the London beer flood, which is, yeah, it was pretty similar. A few million gallons of beer spilled and it killed eight people and maybe a ninth from alcohol poisoning. It's not really clear. And the neighborhood was really mad and they held a trial and the result was that it was an act of God. Now I ask you, why do you think that engineers haven't been really held as accountable as maybe they should? And I would argue that it's because to a large portion of the community, what we do is kind of magic and if you don't understand something, it's easy to just accept it and to not be able to demand accountability. So we don't use this language, but it's a similar thought. So the molasses flood was different and I would argue that it's because people had to walk around in their sticky neighborhood and sit on their sticky train seats and they had basically landed in the molasses swamp in Candyland and they're stuck there and it's not fun. And when you can't forget something, when you can't forget something, you have to engage with it and that's what brought about change. So may this stick with you, when you walk into your job on Thursday or Monday or whatever, maybe your shoes are kind of sticking to the ground and you reach for your keyboard and it's kind of gross and you can really forget that. And don't forget this either. You build products for people and they deserve your attention and your care, your consideration and it's okay to have a little molasses if that helps you remember it. So thank you all. This is my contact info, Hailey Denby on Twitter and thank you very, very much. Thank you.
there if you're nice. I'm a software developer. I what we do and how we might approach it in a responsible to the public for both of these a hospital, rather. And more than 3,000 years with the pressure of the tank and millions of system of licensure which you could also call of civil engineering and the reason that they to talk about it. I'm going to do that through title of software engineer. The title of software Sometimes we write code that isn't going to hurt first Bowser castle. So our princess isn't in industry standard. A good place for you to start that's where you can begin your learning on this like the impact of your code is going to be at do know is I have a lot of people that I work suggestion is to pretend that you're licensed and pretend like you are bound to some professional accountable for what you write. So promoting