We Are 3000 Years Behind... by Hayley Denbraver

This video features Hayley Denbraver at DjangoCon US 2018 in San Diego, California, USA.

We Are 3000 Years Behind... by Hayley Denbraver
0:25:43
Published November 8, 2018
394 views

DjangoCon US 2018 - We Are 3000 Years Behind: Let's Talk About Engineering Ethics by Hayley Denbraver

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.

This talk was presented at: https://2018.djangocon.us/talk/we-are-3000-years-behind-let-s-talk/

LINKS:
Follow Hayley Denbraver 👇
On Twitter: https://twitter.com/hayleydenb

Follow DjangCon US 👇
https://twitter.com/djangocon

Follow DEFNA 👇
https://twitter.com/defnado
https://www.defna.org/

Summary

Software developers build products that affect people, so they should treat ethics as part of professional practice rather than an optional concern. Hayley Denbraver contrasts software engineering with civil engineering, where licensure creates formal accountability, and argues that the largely unregulated “software engineer” title leaves the public with fewer ways to demand responsibility. Drawing on the Code of Hammurabi, engineering licensure, and disasters such as the Boston molasses flood, she recommends building ethical literacy, taking code review in proportion to potential impact, making seniority meaningful through mentorship, improving communication so concerns can be raised, and acting as if one’s work were subject to a professional license. Her central argument is that software’s complexity can make harmful outcomes seem like magic, but developers must remember that real people live with the consequences of what they build.

Key takeaways

  • The title “software engineer” does not generally carry the protected status, licensure, or public accountability associated with civil engineering.
  • Technical mistakes and unethical choices can overlap with harmful outcomes, so developers should actively minimize that risk.
  • Ethical literacy should be treated as a professional skill, beginning with resources such as the ACM Code of Ethics.
  • Code review should reflect the potential impact of the work, with especially consequential systems receiving serious and possibly independent review.
  • Teams need meaningful mentorship, clear communication, and a willingness to act as though developers are personally accountable for the code they produce.

Summarised automatically from the transcript.

Transcript

3,435 words · auto-generated Show

Automatically transcribed, so expect mistakes in names and technical terms.

0:16

I'm really happy so many of you came out to be lectured uh at 5 p. m. Um I it's only a little preachy. Just a little. Uh anyway, my name is Haley Dunbraver and my talk is ominously called We Are Three Thousand Years Behind. Let's Talk About Engineering Ethics. And Here's some of my contact info. My name's Hailey Dunbrever. You can tweet at me there if you're nice. I'm a software developer. I 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 lucked into this

1:01

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. And you can't really ignore it just like these newsies throwing newspapers in your face. And you know, we've had to engage with these maybe scariish stories um about code gone wrong that um this is just a topic that

1:49

the people organizing conferences want the community to engage in. So what are some of these stories? Right? Well, they range in severity. They touch a number of different industries. They can range from anything to election meddling to uh there was a story recently about Wells Fargo, they had a some kind of software bug and they foreclosed on a bunch of people's homes without the proper review. And like that's kind of scary. And so's 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.

2:37

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 Venn 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 uh some kind of loss, a failure, some kind of pain suffering. I bad thing, right? And you know, I could be immoral, and that would fall in the yellow circle.

3:25

And these are the sort of things that um Jiminy Cricket, the little um cricket on your shoulder, your conscience, would kind of give you a bad feeling about, like, I don't know, 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 you know, 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.

4:13

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 used 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 that was the fun one and then the and then the the hotel near Disneyland that was the boring one or maybe it was the other way around

4:59

But um the the Disneyland the hotel near Disneyland really was my favorite. But like these are a wide variety of jobs and uh I was responsible to the public for both of these things and uh want to kind of dive into that a little bit. Now, my former profession was really, really old. These are old examples of engineering, and 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

5:46

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 gonna 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. Uh most of the code of Hammurabi is this grisly if-then statements kind of things. And uh you might better know

6:31

that form as an I for an I, right? 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 SAR of 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.

7:17

Okay. No, no, no. If it kills a 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 inasmuch 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 walls solid from his own meats. 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

8:03

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 gonna hope that that's true

8:48

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 but we're gonna roll with that. And we're gonna talk about the 1919 Boston molasses flood. All right. So in January of nineteen nineteen, a tank failed in uh a neighborhood in Boston and uh the structural defect the with the pressure of the 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.

9:35

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 gatekeeping. So no longer eye for eye, but Gretchen saying you can't sit with us. Right. Now, uh, this is the current department that regulates uh practice of civil engineering. And the reason that they license individuals is to restrict practice to people

10:23

who have proven themselves through their educational credits, test taking, and um work experience. to be capable of doing these sorts of jobs, right? 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. And I'm going to do that through a 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 dun dun dun dun

11:10

dun dun dun and then I graduated from an accredited university and it was exciting and I didn't throw my hat. Did anybody throw their hat But um yeah, this was me undergrad. Then I did some one-handed push-ups because I was 22 and 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 uh then I took up running because it was kind of stressful. That point

11:55

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 scene and a montage. Thank you for uh tolerating my gifts. I I appreciate that. Now Like I said, licensure is a system of formalized responsibility. None of this montage means that I

12:42

was moral or good, but it meant that I had kind of cleared a background check. Uh 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 gonna do that right now. Right? 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 uh these two careers? Now, I'm gonna start it off with kind of a bummer and tell you the unfortunate truth about the title of software engineer.

13:28

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, Haley Dunbraver, software engineer. And I kind of looked at them, side-eyed them, and went, mm, 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 Haley Dembraver MD and tried to teat treat patients like you you can't do that. It's a protected title. At least in America, software engineer is not.

14:14

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. All right. 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

15:00

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. Right? So that was a really big difference. Well what's another difference? Oh these are the uh the varied and awesome gophers that uh write Go code I wanted Pythons, but the gophers are really cute. So that's what we went. So what's another difference? Well, there's a difference in how the work is evaluated. Pushing to GitHub and opening PRs and reviewing code is absolutely necessary.

15:49

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 uh forever and you know can be Brought up years and years later. Like it's just not the same thing, right? What'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?

16:35

Well, it's okay to not know what you're doing all the time. Alright, sometimes we write code that isn't gonna hurt anybody. I personally think that none of you has written code that has drowned anyone in molasses. I know I haven't. So, you know, if you feel like this dog ever, like that's that's okay. You know, he's he's a good boy. Uh he would never hurt anybody, all right Um and we do have some rules with respect to to how we operate. There are rules about private information, there's rules about health data.

17:21

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? We don't really know the future, but It's possible that we're gonna 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 like you have to start somewhere.

18:06

So we're gonna 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 has You know, 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

18:53

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

19:38

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 I would recommend getting some outside help even if it 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 backgrounds, but we could have, am I okay? Okay, that's perfect. So seniors should mean something.

20:24

And by that I mean that while we have a diversity of backgrounds, 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 a 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

21:14

that. Um You no, no, no, no. And 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 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.

22:00

My co-workers 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 get blame is like carved into stone and that you're accountable for what you write. So

22:46

promoting ethical literacy, taking review more seriously, seniors should mean something, proving communication, and pretending you're licensed. Now in the last few seconds, I'm gonna revisit the molasses flood. A bunch of people died in molasses, really terrible. Terrible, terrible. 100 years before that, there was something called the London Beer Flood, which is Yeah, it was pretty similar. A uh few million gallons of beer spilled and it killed eight people and maybe a ninth from alcohol poisoning. It's not really clear. And uh they they the neighborhood was really mad and they held a trial

23:34

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

24:21

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 what it whenever. Maybe your shoes are kind of sticking to the ground and you reach for your keyboard and it's kind of gross. And you couldn't really forget that. And don't forget this either. You build Products for people

25:07

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, Haley Dunby on Twitter, and thank you very, very much

Questions this talk answers

What does the title “software engineer” actually mean?

Unlike “civil engineer,” which is a protected title requiring licensure in the United States, “software engineer” is generally not legally protected. It may matter within an organization or career path, but it does not by itself establish responsibility to the public or a standard the public can rely on.

Discussed at 13:28

How can software developers practice engineering ethics?

The speaker recommends building ethical literacy, taking code review seriously in proportion to a system’s potential impact, making seniority involve mentorship and professional practice, improving communication so concerns can be raised, and acting as though your work were subject to a professional license.

Discussed at 18:06

Why should software developers take code review more seriously?

Review should reflect the possible impact of the code rather than becoming automatic rubber-stamping. For highly consequential code that could harm people, the speaker recommends bringing in outside reviewers and getting fresh eyes on the work.

Discussed at 18:38

Why should software developers act as if they are licensed?

Treating your work as if you had to stamp and personally stand behind it encourages accountability: you should be willing to put your name on what you write and behave as though a professional code applies to you.

Discussed at 22:00

Why are software engineers less accountable than civil engineers?

The speaker argues that much of the community sees software as a kind of magic and therefore has difficulty demanding accountability. People became more engaged after disasters such as the Boston molasses flood because the consequences were tangible and impossible to ignore.

Discussed at 23:34

Note: We understand that names change, people change, and bodies change. We respect each individual's journey and privacy. If you have any concerns about a video or need us to remove content, please don't hesitate to contact us. We will handle your request with care and promptly address any issues.

More videos by Hayley Denbraver

More videos from DjangoCon US