@mhoye Great question!

I'd probably start with complexity (Fred Brooks "No Silver Bullet" and maybe "Out of the Tar Pit"). You could potentially frame all software culture as a philosophical approach to complexity: managing/reducing it.

Probably then I'd want to look at hacker culture (Cliff Stoll? Morris worm, Mitnick, captain Crunch) and then talk about open source (The Cathedral and the Bazaar).

It's maybe odd that open-source software practices became common in industry.

@mhoye

- a look at the typical artefacts found in software repos and the infrastructure around them. So from README/LICENSE/CONTRIB through badges in README, to dependabot, etc. As a way to publish to norms and navigate a project

- implicit and explicit norms around bug reporting and pull requests

- project archetypes and maintenance styles, see e.g. Nadia Eghbal book.

- primer on different licences and their intent

@mhoye a cultural anthropology of computing is a very broad topic. I see some of the replies are on common modern software development practices, which is useful but seems pretty narrow.

I think going into the actual cultural sub-groups that have come and gone over the past ~80 years would make more sense to me. How programming was considered women's work in the US in the early days, then co-opted by men as prestige in the work went up, how the Cold War affected software licensing and sharing, the GNU reaction to that (and you gotta include a picture of "Saint IGNUcius" just for fun here), the development of other OSS groups like Apache and the creative commons once the internet became common. There should be some talk about the broader impact of these things on the rest of the world just as the rest of the world helped shape these things.

Finally the end of it could be going into various common subgroups in existence today and what practices they follow, not judging which are best.

@mhoye You need to design for the workflow of your users and around the pain points of your users. This means before you write a single line of code you need to map what the users are doing first.

So the course has to drill that into students plus teaching participant observation and semi-structured interviewing.

@mhoye

- Engineering Disease is real
- Spending too much time on Hacker News can rot your brain and reduce your capacity for Human Empathy
- Ditto Reddit
- When building something that Bad agents could easily use to cause harm to others, never assume that 'Nobody would ever do X'. Ensure that doing X is more trouble than it's worth for the Bad Agents.
- When testing software / products make sure to have more women as test subjects, actually more minorities in general

@mhoye

I've had the outline of a lightning talk in my head for a while. It goes like this:

Here are the significant tech advances of the last N years:

[jumble of logos]

And here are the successful tech startups of the last N years:

[more logos]

And here's the overlap:

[ Venn diagram showing almost none]

In your tech life, you contribute to something significant and you may get rich, but you won't do both.

Plan accordingly.

@mhoye Lots of great answers already in the thread. I think that, in 2024, there needs to be at least one session on "ML/AI In Practice"...

* how is training a model different than writing an algorithm
* how to think about data, about training, about inference
* how to improve the quality of a classifier, a predictor, a transformer
* what people with ML/AI backgrounds expect to get from software engineers, and what you should expect from them
* how to talk about safety, bias, and error

@mhoye I want to take it, not teach it. 

I suppose a bit on the evolution of source management would be neat.

Go over various philosophies towards testing and documentation. Bias this towards DOING THEM.

How to look through a codebase and extract information about the culture by identifying things about the code over time, making like... Code Strata. But first I'd have to lean to do that myself.

@mhoye

Amazing thread! And makes me think 10 weeks is not at all enough :-)

@mhoye I don't feel qualified to come up with a whole course outline, but here are some things I'd for sure want to put in:

-success and failures in abstraction, generalization, and specialization, to help make the students more thoughtful of not just how but whether to apply more of one of those to a project
-showing how the interpretation of common phrases/concepts, like "object oriented", have had varied and evolving interpretations, and how different languages, patterns, and guidelines have approached the supposedly-same idea in different ways
-compare different language and library abstractions that fulfill the same objective, such as comparing exceptions and sentinel values to sum types

@mhoye You absolutely need to teach filesystems now (meaning: how files are organized in directories ("folders")) because most kids these days(tm) do not get in contact with regular files any more. And this lack of understanding will make it much harder to teach some of the other concepts.

Also, you need to know about ASCII (and please build UTF-8 on top of that).

Stuff from XEROX Parc doesn't hurt (early computer interaction), early computer graphics (conway's game of life) is always nice.

@mhoye depends a bit on the program you're doing this for. Is this more software engineers or more mathematical computer scientists?

Anyways, probably run them through the gamut of things that software actually is used for (electrical engineers in safety-critical disciplines are sometimes a bit confused about the break things and maybe move fast philosophy of modern web-centered SE; people in modern software companies by the lack of good tooling in embedded. Aerospace by the lack of req. eng.;