Why Ethics Is an Engineering Discipline: Codes, Responsibility, and the Weight of the Build

Hook #

For most of this curriculum, the questions have been can — can I make this correct, fast, secure, scalable? This course asks a question that is easy to skip and impossible to unask once you have seen it clearly: should I build this, and who is responsible when it causes harm? It is tempting to file ethics under "soft skills" or "someone else's job" — the product manager decides what to build, the lawyer handles compliance, the engineer just implements. That division is a comforting fiction, and this course is about why it fails. The person who writes the code is not a neutral instrument; they are the last line of defense between an idea and its consequences in the world, and "I just built what I was told" has never, in any serious accounting, been a complete answer. Software now decides who gets a loan, whose résumé a hiring system surfaces, how much radiation a cancer patient receives, whether an aircraft pushes its own nose toward the ground. The engineer who builds those systems holds real power over real lives, and this first lesson is about taking that seriously: what professional ethics is (not vague virtue, but a discipline with codes, standards, and hard-won lessons), why it is engineering rather than philosophy, and why the weight of the build lands, in the end, on the person doing the building.

What you'll be able to do by the end of this lesson #

• Explain why software ethics is a professional discipline (like a doctor's or an engineer's licensure ethics) rather than personal opinion, and what the ACM Code of Ethics actually asks of practitioners.
• Reject the "I just built the tool" fallacy — the idea that engineers bear no responsibility for how their work is used — and articulate why the builder holds responsibility that can't be fully delegated.
• Explain the responsibility gap: how harm from software often results from diffuse decisions across many people, and why that diffusion makes individual accountability easier to evade but no less real.
• Use the Therac-25 case as a concrete anchor for how ordinary engineering decisions — skipped reviews, dismissed bug reports, reused code, absent safeguards — compound into life-and-death failure.

A quick try before we start #

You're an engineer on a hiring tool. Your team lead says: "Train the résumé-ranker on the last ten years of who we hired and promoted — that's our ground truth for a good candidate." It's a reasonable-sounding instruction, it hits the deadline, and it's clearly "just doing your job." Now think one step further: if the company's past hiring under-hired women or minorities (as most have), your model will learn that pattern as the definition of "good" and reproduce it at scale, with an algorithm's veneer of objectivity — and it will do so because you followed the instruction competently. Here's the ethical question this course trains: at what point does "I just implemented the spec" stop being a defense? You are the person who knows the training data encodes past discrimination — the team lead may not, the executives certainly don't. The knowledge, and therefore a share of the responsibility, is yours precisely because you're the one close enough to the machine to see it. Noticing that the engineer is often the only person positioned to see the harm coming — and that this positioning creates obligation — is the entire premise of professional ethics.

Why this matters here #

This lesson opens the Ethics course by establishing why the course exists at all — why a CS curriculum that has spent years on algorithms and systems ends with a serious treatment of responsibility. The answer is that technical skill without ethical judgment is not neutral; it's more dangerous, because it makes you more capable of building things that scale harm efficiently. Everything in this course — privacy, algorithmic bias, intellectual property, environmental cost, whistleblowing — is a specific domain of the general question this lesson raises: what do you owe the people affected by what you build? This lesson is also where the whole curriculum's technical content gets recontextualized: the security mindset you learned (threat-model, assume harm) is already ethical reasoning (whose harm? at whose hands?); the code-review and professional-practice disciplines from the software-engineering course are already mechanisms of collective responsibility (a review is where a colleague catches the harm you missed). Ethics isn't bolted onto engineering here — the lesson's claim is that it was always part of it, and this course makes it explicit.

For a working engineer, this is among the most practically important and most under-taught material in the entire curriculum, because the situations are real and common — not exotic trolley problems but the everyday texture of the job: the deadline that pressures you to skip the accessibility work, the metric that optimizes engagement by exploiting attention, the data collection that's "technically consented" but actually deceptive, the security bug you could ship quietly or disclose responsibly. The engineers who navigate these well aren't the ones with the most philosophy; they're the ones who've thought about it in advance — who have a framework (like the ACM Code), who've internalized cases like Therac-25, and who've decided before the pressure hits where their lines are. Because the hard truth is that ethical failures in software rarely look like villainy in the moment; they look like reasonable people making locally-reasonable decisions under deadline, each small step defensible, the sum catastrophic. Recognizing that pattern — and building the professional habit of asking "who could this harm, and am I the one who can see it?" — is a genuine engineering skill, as learnable as debugging, and far more consequential when it matters. It's also, increasingly, a career reality: the engineer who can reason clearly about the ethics of what they build is more valuable, more trusted, and better positioned to lead than the one who treats it as someone else's department.

The engineer's lens #

The first lens is professional ethics as a discipline, not a mood — the recognition that mature professions codify responsibility precisely because good intentions and personal conscience are not reliable enough on their own. When a bridge collapses, we don't say "well, the engineer meant well"; there are professional standards, codes, and accountability, because society learned that the power to build things that can kill people requires institutionalized responsibility, not just individual virtue. Software is a young profession still learning this, and the ACM Code of Ethics is the field's most serious attempt at it. Crucially, the Code is not vague sloganeering — it makes concrete claims that translate into decisions: avoid harm (and when harm is unavoidable, minimize it and be transparent), be honest and trustworthy (don't deceive users about what your software does), respect privacy, give credit, accept and provide appropriate professional review. Read it and you'll notice it reads like a specification for professional conduct — testable assertions, not platitudes. The value of a code is exactly the value of any specification (a concept you know well from the software-construction course): it makes the implicit explicit, gives you shared vocabulary to raise a concern ("this violates the honesty principle" is more actionable than "this feels wrong"), and provides something to point to when you need to push back. The deeper point is that treating ethics as a discipline — something you study, practice, and hold yourself to standards on — rather than a matter of personal taste is what makes it usable under pressure. Personal conscience wavers when the deadline looms and the boss is impatient; a professional standard you've internalized in advance is a firmer place to stand. This is the same reason engineers value codified practices (tests, reviews, runbooks) over "being careful": the code externalizes judgment into something reliable.

The second lens is the "I just built the tool" fallacy and the responsibility gap — the two intertwined evasions that let harm happen with no one feeling responsible, and why the engineer's proximity to the machine makes the evasion illegitimate for them specifically. The fallacy is the claim that tools are neutral and responsibility lies entirely with the user: "I just built the algorithm / the platform / the weapon-targeting system; what people do with it isn't on me." This is seductive because it's partially true (users do bear responsibility) and completely inadequate as a full defense — because design choices are not neutral. A social platform that optimizes for engagement chooses to amplify outrage because outrage is engaging; a facial-recognition system chooses whose faces it was trained to recognize accurately; a "move fast" data pipeline chooses to collect more than it needs. The builder embeds values into the artifact, and pretending the artifact is a blank instrument is how those embedded values escape scrutiny. The responsibility gap is the structural companion to the fallacy: in a large organization, a harmful outcome is the product of many diffuse decisions — the PM specced it, the designer shaped it, the executive prioritized it, the engineer built it, the legal team blessed it — so each participant can plausibly say "my part was small and reasonable," and responsibility diffuses until no one owns it. This diffusion is real and it's exactly how large-scale harms happen (few are the work of a mustache-twirling villain; most are the sum of many people not-quite-owning their piece). But here is the lens that matters for you as the engineer: you are frequently the person closest to the machine — the one who actually sees the training data, understands what the system will really do, notices the edge case that will hurt someone. That proximity means you often know things the others don't, and knowledge creates obligation: the responsibility gap lets others honestly not-see, but it doesn't excuse you, because you're positioned to see. The professional stance isn't "it's all on me" (that's neither true nor sustainable) — it's "my share is real, it's proportional to what I can see and affect, and I don't get to disclaim it just because responsibility is diffuse." Recognizing that diffusion of responsibility is a feature of how harm happens, not a valid excuse for participating in it, is the core ethical competency this lesson builds.

The third lens is Therac-25 as the archetype — the case that proves ethics is engineering, because the deaths came not from malice but from a chain of ordinary, individually-defensible engineering decisions with no one exercising the responsibility to say "this isn't safe enough." Therac-25 was a radiation-therapy machine (1980s) whose software defects caused massive radiation overdoses that killed and maimed patients. What makes it the canonical case is that there was no villain — just a series of normal-looking engineering choices that compounded fatally: safety interlocks that had previously been hardware were moved to software (removing a physical safeguard, trusting code to be correct); code was reused from an earlier model without re-validating it in the new context; a race condition (which you now understand deeply from the concurrency courses) triggered only when an operator typed quickly, so it was hard to reproduce and easy to dismiss; bug reports from clinicians were rationalized away ("the machine can't do that") rather than investigated; there was no independent code review of safety-critical software; and error messages were cryptic ("MALFUNCTION 54") so operators couldn't tell a dangerous fault from a routine one and learned to just clear them and proceed. Every one of these decisions was defensible in isolation — reuse code (efficient!), trust the software (it worked before!), the machine surely can't overdose (there are limits!) — and together they killed people. This is why the case is the moral center of the course: it demonstrates that catastrophic ethical failure in software usually isn't a dramatic choice between good and evil; it's the accumulation of ordinary technical decisions made without anyone taking responsibility for the whole, for the person on the other end. The lessons are directly technical and directly ethical, which is the point: independent review of safety-critical code (an ethical obligation and an engineering practice), taking bug reports seriously especially when you can't reproduce them (a race condition you can't reproduce is still real — the "make it fail reliably is hard" problem from the debugging lesson, here with lives at stake), designing error messages that convey severity, and never removing a safeguard without understanding what it protected against. Therac-25 is the proof of this lesson's whole thesis: ethics and engineering are not separate domains — the ethical failure was an engineering failure and vice versa, and the engineer who does the technical work well (reviews, takes reports seriously, respects safeguards, communicates clearly) is simultaneously doing the ethical work. Carry this case as the touchstone for the rest of the course: when you wonder whether some abstract principle really matters, remember that "MALFUNCTION 54" was a real error message that real people cleared before real patients died.

What to focus on in the resources #

• The ACM Code of Ethics — primary. Read the General Principles and Professional Responsibilities. Notice it's a specification for conduct — concrete, testable claims (avoid harm, be honest, seek review) — not platitudes. It's the shared vocabulary that makes raising a concern actionable.
• The Therac-25 case (Leveson & Turner). Read for how a chain of ordinary decisions — moved safeguards, reused code, dismissed reports, no review, cryptic errors — compounded into deaths with no villain. This is the course's moral anchor and the proof that ethics is engineering.
• The ACM's worked case studies. These model the actual skill: taking a principle and reasoning to a decision under real constraints (deadline, boss, incomplete info). That reasoning-to-a-decision is what this course trains.
• Skip on first pass: the philosophical taxonomy of ethical theories (deontology vs. consequentialism vs. virtue ethics) — useful background, but this course is about professional practice, not moral philosophy. Get: ethics-as-discipline (the Code as spec), the "just built the tool" fallacy + responsibility gap, and Therac-25 as the archetype of harm-by-accumulation.

Explain it back #

Explain to a colleague why "I just built what I was told" isn't a complete ethical defense, and why Therac-25 shows that ethics is engineering. A strong answer: software now decides loans, hiring, medical doses, and aircraft behavior, so the person who writes the code holds real power over real lives — and design choices aren't neutral (a system that optimizes engagement chooses to amplify outrage; a model trained on biased history learns the bias). The "I just built the tool" fallacy pretends the artifact is a blank instrument, hiding the values the builder embedded. The responsibility gap is its structural partner: in a big org, harm is the sum of many diffuse, individually-reasonable decisions, so everyone can say "my part was small" and no one owns it — which is how large harms happen, not a valid excuse. The key point for the engineer: you're usually closest to the machine, so you see things others don't (the biased training data, the edge case that hurts someone), and that knowledge creates a proportional, non-disclaimable share of responsibility. Therac-25 proves ethics is engineering: a radiation machine killed patients not through malice but through a chain of ordinary, individually-defensible decisions — safeguards moved from hardware to software, reused code, a race condition dismissed because it couldn't be reproduced, no independent review, cryptic error messages operators learned to clear. Every choice was defensible alone; together they were fatal. The ethical failure was the engineering failure — which is why doing the technical work well (review, taking reports seriously, respecting safeguards) is the ethical work. Bonus: the ACM Code is a specification for conduct — concrete, testable, and a firmer place to stand under pressure than personal conscience.

Where this connects #

Backward: The security mindset (threat-model, assume harm) from the security course is already ethical reasoning — whose harm, at whose hands. The code-review and professional-practice disciplines from the software-engineering course are already mechanisms of collective responsibility (independent review is exactly what Therac-25 lacked). And Therac-25's race condition is the concurrency material from the OS and parallel courses, now with lives at stake — a vivid reminder that "hard to reproduce" doesn't mean "not real."

Forward: This lesson's general question — what do you owe the people affected by what you build? — becomes specific in every lesson that follows: privacy and surveillance (what you owe people about their data), algorithmic bias (what you owe people the system judges), intellectual property (what you owe other creators), and environmental cost and whistleblowing (what you owe the wider world, and when the duty to refuse overrides the instruction to build). The Boeing 737 MAX case in the final lesson is Therac-25's modern echo — the same harm-by-accumulation, at even larger scale.