30 comments

[ 2.9 ms ] story [ 71.5 ms ] thread
Is there room for education on when things go south?

Effective Whistleblowing

Privacy-Preserving Patterns

Ethical SLAs, SLOs, and SLIs

Ethical SRE in the Time of AI

Core Protest Principles

Nonviolent Resistance

Change from Within: Studies in Commerce

Fundamentally, even if we know it to be wrong, and a market exists for it, what is the game-theoretic, optimal strategy? What is the ethical choice?

Leave DIE to the humanities and arts majors please.
Why? It seems like something more CS students could learn about.
The should learn about it in the same way that they should learn about other ideologies: not to make them their own but to be aware of their existence and their goals. History is there to be learnt from so as to avoid making the same mistake twice or more often so it is important for anyone to realise that DEI [1,2,3] is another term for critical social justice which is derived from critical theory [4] which is an expansion of Marxism meant to address the "faults" of the ideology which had kept the predicted revolutions from occurring in the early 1900's. Learn about it by all means, the more people learn about it the better they will be prepared when they are confronted by one if its many offshoots.

[1] https://newdiscourses.com/tftw-diversity/

[2] https://newdiscourses.com/tftw-equity/

[3] https://newdiscourses.com/tftw-inclusion/

[4] https://newdiscourses.com/tftw-critical-theory/

Ethics isn’t part of DEI. Ethics is a subject that humanity has been pondering over for thousands of years - it’s way older than the modern trends of focusing on diversity and inclusion.

At my university ethics was a required subject for all engineering students. (And this is long before DEI was a thing). We had a special ethics course with a CS focus and CS TAs. The content included looking at lots of ethical frameworks (eg Kant, rule utilitarianism, etc) and analysing different choices or actions through those lenses. There’s lots of examples from CS history where software (intentionally or otherwise) has caused human suffering or deaths. We talked about them, not prescriptively but to help decide for ourselves what we would want to do if we are ever placed in a similar situation as those engineers.

It’s good stuff.

I’m not sure if it’s a direct result of that course, but I’ve been horrified over the years by some of the opinions I’ve seen here on HN when ethics comes up. Stuff like “well yes lying directly to your customers and chronically underinvesting in information security is unfortunate, but would you really want to risk your job over it? They’d fire you and get someone else!”. Argh yes! Kick up a fuss! You probably won’t lose your job. You will probably get more respect in your organisation, from the right people. In my opinion, you are responsible for the outcomes of your work. As a software engineer on the ground, the computer is literally doing your bidding. Would you personally lie to the face of thousands of your customers? If no, why are ok with telling the computer to do it on your behalf?

We have power in society as engineers. Ethics asks us the question of how we want to wield that power. It’s much deeper question than preachy DEI stuff.

Not sure what you're on about. The linked page specifically references another page which mentions DEI by name: https://identity.cs.duke.edu/

"Both computing departments and tech organizations have long struggled with issues related to diversity, equity, and inclusion."

It looks to me like you're using ethics as the motte.

DEI concerns comprise a subset of ethics, not the other way around. This isn't hard.
> It looks to me like you're using ethics as the motte

My goal in talking about ethics isn’t to protect DEI. It’s to have it be subsumed by something which I believe is bigger, broader, more mature and more relevant to engineering work. The study of ethical theory is all of those things.

Concretely, as engineers I think we need to be thinking and talking a lot more about the harm caused to society by security breaches, dark patterns, social media addiction in teens, loneliness and depression amongst the video game community, dystopian pervasive workplace tracking and monitoring, online gambling and I’m sure other problems. This stuff causes real harm.

But what do people campaign for instead? Oh, renaming git’s “master” branch to “main” and changing “blacklist” to “deny list”. And adding trigger warnings all over the place, despite increasing evidence showing it does more harm than good to victims of trauma.

If DEI is important, let’s give people the language and skills to engage in ethical arguments, as people have been doing for thousands of years. An honest, informed debate makes us all smarter. The modern finger wagging moralising that happens with DEI stuff is an embarrassment.

Someone who really understands a topic should be able to argue convincingly for or against their own position. The whole point of the academy is to teach these skills.

It's important that this sort of thing stick to general principles and not pander to the popular topics of the day.
Social responsibility is about more than newly mainstream DEI programs. ACM and IEEE have promulgated professional codes of ethics for a while. Social responsibility can involve questions about everything from AI concerns (which HN has no qualms talking about) to whether to add a stored payment option (credit card numbers) on a POS terminal that you know will be deployed with no protections to saying "no" when a client that's an insurance carrier says they want their self-service online claims system to refuse to accept a submission unless a checkbox is ticked that explicitly opts the submitter in to forms of correspondence that work to the submitter's disadvantage (e.g. non-written), including overriding what preferences/demands they've communicated to the carrier in the past. I think every course I took that was offered under the umbrella of the college of engineering at my school had a mandate that the instructor spend one week (2–3 classes) out of the semester on professional ethics, complete with HBS-style case studies. And this wasn't recently.

Related: this month's issue of Communications of the ACM also has an obvious focus. <https://cacm.acm.org/magazines/2023/5>

It would be nice if there were some sort of industry protection for engineers who do refuse unethical tasks. At present, I'd expect you'd get fired pretty quickly if you said no (at a lot of companies).
Most "software engineers" don't have licenses/credentials backing up their job title, anyway. Compared to other industries, it's lightly regulated at best. So long as that's the case, I think the current balance, which includes the possibility that a programmer will be dismissed for failure to comply, is reasonable. From an HR and PR standpoint, companies who do so will be facing the threat of blowback related to disclosure that a programmer was fired for using their judgment on an ethics question rather than taking orders. That's not nothing.
> That's not nothing

Any thoughts on how most ignored the "software engineer" from Google and his thoughts on their AI? [0] I know personally I tended to ignore it and let it get buried. However, in this sort of context I do wonder what would make something like that actually effective in persuading others.

https://www.theguardian.com/technology/2022/jun/12/google-en...

Software engineers tend to be pretty anti-union (or at least, union-agnostic).

This is among the kinds of protections unions grant industry professionals in other industries.

Yeah I think this ties into not only the fact that we are highly paid, but also how unions generally form. When everyone works at a factory and have similar positions, you can stand outside and hand out flyers and have face to face conversations. With programmers, you might have a few others on your team that match your job description, then PMs, managers, designers, etc. Imagine trying to get a portion of the engineers at a midsize company together and you won't even have enough power to do anything but get yourselves fired.

To me, this is why if you want a more ethically bound software industry, you need regulation, not unionization.

Social responsibility is not programming a nuclear warhead to target Moscow but target an arbitrary location which happens to be the location of Moscow.
Agree, not sure why software engineers believe that engineering ethics is about doing what's in the users interest and what's morally correct. In most of the traditional engineering professions, the ethics course is mostly about building bridges that don't fail, and weapons that work as expected. If engineering ethics is about doing what morally right, then aerospace and mechanical engineers are the greatest sinners in the world. Engineering codes of conduct with legally binding power usually involve building things to specifications and things that won't fail (based on the specification). They don't make any prescriptions about the ethics of building a hypersonic missile or a tracking users en masse.

Beware what you wish for, these rules exist to bind and regulate engineers. They are exist so capital holders can feel secure about their return on investment. Unless you want this https://news.ycombinator.com/item?id=35970283 to become reality, better push back attempts to regulate software engineering.

That's 3/4 of it, knowing when to say no. The other 1/4 is knowing when to say yes ;) so you can sabotage the project later.
(comment deleted)
Social responsibility in CS, in my experience, means that if a given function doesn't produce equal outputs for two given inputs, all it takes to suggest that the function is biased is an assertion that the outputs should have been the same if the function weren't biased. How different the inputs were, even along the criteria that the function actually uses in order to produce its output, is completely irrelevant.
Functions are tools for humans to cause the computer to achieve a desired output. If the function isn't generating the desired output, change the function.

We can talk all day about how the history of facial recognition has used things like the eye-nose-mouth T-shape or high-contrast contours to lock in on the target, but if at the end of the day the solution works for people with light skin and not people with dark skin, "HP computers are racist" for every meaningful (i.e. user-experienced) definition of the concept. (reference: https://www.youtube.com/watch?v=t4DT3tQqgRM)

> How different the inputs were, even along the criteria that the function actually uses in order to produce its output, is completely irrelevant

This is why I said this.

The example you gave, where software was trained on people with lighter skin and therefore doesn't produce the intended results on people with darker skin, is noncontroversially racially biased. As in, control for everything but skin color, and the color of someone's skin is actually a parameter that the function "uses" in order to produce its output. For this reason, people tend to agree that this is an actual problem with the program that needs fixing.

I follow. Can you give a concrete example of what you mean? "How different the inputs were, even along the criteria that the function actually uses in order to produce its output, is completely irrelevant..." In what context did this come up?
(comment deleted)
You get responsibility with skin in the game. Software engineers should be liable for the software they produce.
Do it for the business majors first
(comment deleted)
During your career as a software developer, it is inevitable that you will have to interact with social scientists and other activists who care a lot about investigating your work for potential biases. It’s normal to have an initial reaction to this curriculum suggestion along the lines of “this is irrelevant, teach me about data structures and control flow instead”, but I would encourage you to view it useful practice for challenges you will likely encounter. After all, a bad answer to these challenges is much more likely to get you fired than other mistakes like causing an outage or pushing inefficient code to production.
This would've been easier to institute in the '90s.

For around 20 years, CS departments have been pipelines to "greed is good" careers.

It'll be interesting to see whether it gets genuine traction, and what will have to happen before then.