 Lazyweb, a question: let's say that you could teach a "cultural anthropology" type of course about computing to first year students, to prepare them for the codebases, communities, patterns and software philosophies of the programming world. You've got about ten weeks to run it. What would you teach in that course and why? (RTs appreciated for reach.) 139 comments
 @mhoye @inthehands @mhoye I was going to reply with "learn how to communicate and learn to ask 'why?'" but you've put it far more eloquently in this thread. @badlydrawn @mhoye @inthehands @mhoye funny coincidence ... I was trying to explain the idea of a stuck record to some younger team members only yesterday.  @mhoye first of all, a "how to work in teams" course or ten is apparently badly needed given my experience hiring recent CS grads, so this is a great question. I lack the breadth of experience to design such a course that would cover a wide enough range of possibility. But I would start with @mhoye I think detailed examples of several wildly different work groups would be informative. This small team is all senior level and above, they have very lightly written specs, no PM, write all their own tests, bitch a lot but are really fine, etc. This large team has UX including both functional and UI specs, dedicated QA, intricate PM process etc. This gang of adorable cutting edge loons is building a game from their various polycules spread across several time zones. @mhoye I think about this a lot so I'll stop there, I could go on about "things I wish greenies came in knowing that aren't about computer science" for quite awhile I mean the main thing though is software is just ideas and is made by people and so if you got into computers to avoid people you're actually about to get a rude shock, but if you like people you'll actually do great in a healthy workplace Oh God, this Schools are terrible at teaching how to work in teams and junior devs fall into endless rabbit holes because they don't know how and when to ask for help, or let their pride prevent them from asking questions. It would also be delightful to instill a good mentor experience as well, so that they have a less toxic base to work from. @jrconlin @mhoye yep just assume I have to teach most non senior devs how to work in a team. And we have a super healthy communication driven work style where everyone is in everyone's tickets and code all the time so it's a bedrock requirement (outside our platform team which at this point is just super senior staff engineer wizards and another whole style) @mrcompletely @mhoye  @spodlife @mrcompletely @mhoye Yes, this is very true and important. A lot of faculty avoid teamwork themselves. A good research-based tool to improve student teamwork is CATME.org. @JMMaok @mrcompletely @mhoye  @mhoye The first thing I would do is what my own Anth classes did: Start with all the atrocities this field helped enable. Not a very positive start, but it sets the *tone*. You end up thinking, "How can [this code I'm writing] be used for oppression or death?" a *lot*. (I actually took CSci and Cultural Anth in parallel in college.)  @mhoye exactly! I've referred colleagues to specific pages before in response to their insistence on or enforcement of particular organizational processes. "you are literally mandating CIA sabotage as a matter of internal company policy"  @mhoye I would be inoculating them against the UNIX cult for two weeks, teaching the capitalist tragedy of the web for a week, and sending them to therapy for seven weeks @mhoye I know I'd include chapter 5 from "A Voyage to Laputa, etc." in Gulliver's Travels. @mhoye software netiquette and why it exists (how to ask for help, how to write a good bug report, brief explanation of the reasoning behind mailing list etiquette, how to interpret feedback on a code review or technical proposal). Actually the "how to receive code review" one is big in general  @mhoye Day one would be a profanity-laced rant hitting the high spots in @histoftech Programmed Inequality entitled “You may ask yourself, ‘how did I get here?’” @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. - 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 - how to work in public and how it can go wrong - forking, as a process for contribution but also as a means of exercising rights - discussion of different forms of contribution ...are the things that spring to mind. @mhoye I'd like to start with some kind of structured "hackathon" experience that would colocate beginners with more experienced people and let people see what it is like to go from zero to product, give some formal instruction, have another hackthon at the end. I’ve sometimes taught courses where the main assignment was students working in teams to write a case study suitable to be assigned in future iterations of the course. That could work well if the instructor has some background in case study teaching. Having students collaborate on their text drafts using git for version control might be good, because it would separate understanding the process from knowing how to code. (Or that might be terrible, just spitballing here.) @mhoye I actually had an "Introduction to Working in Open Source with the Apache Software Foundation" deck at one of my former employers. It would be too focused for this use, but it could offer some insight into one of the major players in open source development.  @mhoye Hypersummarised: "Lots of people are great at coding. Many of them think that's enough. They are wrong."  @mhoye Something about agile -- what it is, why it arose, the fact that everyone uses this term but no one uses it the same way. Agile manifesto, some of the 18F/USDS stuff (the healthcare.gov diving save is a great case study but also seeing how government navigates this illuminates real-world constraints). Why, because it's ubiquitous, even if more in the breach than the observance - and it lets you pull on threads of why projects succeed/fail. @mhoye Something about allied professions. This is what a UX person does and how it contributes to successful product development. Similarly project manager, product manager, technical writer, etc. Maybe have guest speakers, who are often fun in classes. So they know it's a team sport; that dev isn't the only skill required; and maybe they won't be assholes to these people. @mhoye Some kind of excuse to read at least excerpts from *Unlocking the Clubhouse*, look at graphs of women CS majors pre/post mid-80s, and those studies about how (e.g.) women's PRs are relatively unsuccessful if their name/avi are feminine and relatively successful if not. Because it isn't all meritocracy, that book might be PAINFULLY RELATABLE even now to female students, and also maybe we should stop being like that; there's a hell of a good universe next door. (Generalize to other groups.) @mhoye Maybe something about evaluating a dependency for suitability in a project. This means pulling on licensing but also *the community around the project* : number of stars/forks, do issues get closed (& what's the conversation like), are PRs getting merged, etc. Because software is actually an ecosystem and a lot of learning/dev is social. @mhoye Actually before I did this syllabus I would reread *Kill it with Fire* and I would do anything in my power to get an hour of Marianne Bellotti's time for advice on this question. (She is literally an anthropologist who ended up in computing. Possibly likewise with Jennifer Pahlka's book; lots of interesting stories of software playing out in the real world (...beyond SV because omg the whole world is not SV). @mhoye oh and I might find an excuse to read the therac-25 paper even though it may not strictly be within this course's learning objectives because people should just have read that  @mhoye I teach a course that's within a loud shout of this. It's called "Code and Power." You can find old syllabi on my teaching page: https://dsalo.info/teaching/  @mhoye the things i've had to teach computer science graduates in the past range from "i wish these kids had gotten a methods course re: version control, code review, shell basics" to "i wish somebody had taught these kids to program in any way" to "look, here are some sociopolitical dynamics that you're going to hate for the rest of your career" @mhoye GNU, Cathedral and the Bazaar, version control (CVS, SVN, Git), software licensing ("copyleft"), "embrace, extend, extinguish", StackOverflow, continuous integration ("DevOps"), shareware, SaaS, "sneakernet" (and the arms race of piracy/DRM)  @mhoye a final essay exam question could be "here's a one-paragraph summary of CatB, explain why it resonated in the late-90s and what it got wrong". (You can also borrow from my fav compsci prof, who on occasion assigns "explain this XKCD" as a final exam question...)  @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 Dunning-Kruger, Imposter Syndrome, resulting false self images and their consequences (such as gaslighting and confirmation bias); how to identify this in oneself and one's colleagues, how to protect against it from others, and how to transcend it yourself, and get comfortable with not knowing and with others not knowing. - Engineering Disease is real  @mhoye Maybe run it as a sim? Pick a popular but understaffed open source project, give them a goal of integrating it but also fixing one or more outstanding bugs or popular feature requests and ensuring that the PRs get back into the project. Also give them a continued courseload at the same time, and, ideally, coordinate the assignment with a parallel team at an institution in an opposite time zone (> 5 hours difference) This is intriguing. Would require a lot of consideration to grade them on their cultural anthropology learnings rather than their previous experience with contributing to open source. Huge equity issue in both first year CS and OS community. As you probably both know already. @JMMaok @mhoye Definitely true. I recall someone I knew who was in Colorado State's online MBA program a while back saying that some of the most important lessons they learned were from coordinating team projects with classmates all around the globe, with different first languages, and at varying levels of technical proficiency... I also like reality-based learning. In the movie version of this in my head, the male students leverage their slightly greater level of experience and much greater confidence to dominate the technical aspects of the project, blithely ignoring the lessons of cultural anthropology, until the last week of class when the other students roast them on the cultural anthropology and get As. @JMMaok @mhoye Also true. I lucked out by going to a women's college* for my business degree, so there were many non-male peers and strong support from profs, but even then, this pattern was evident, and we had to be very deliberate about how group decisions were made and responsibility distributed... *non-traditional program was co-ed, but still predominantly non-men  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 @mhoye I assume you have https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness on your list. Possibly through the lens of https://eaves.ca/2009/07/06/structurelessness-feminism-and-open/ @mhoye “The Tyranny of Structurelessness” https://www.wired.com/story/silicon-valley-tyranny-of-structurelessness/ @mhoye “Worse is Better” and all the back and forth follow-ups https://www.dreamsongs.com/WorseIsBetter.html @mhoye “Zero to One,” not as a model to follow but because it explains how a lot of the tech industry thinks. @mhoye I want to take it, not teach it. :owi: 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 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.; @mhoye and this all leads to different company philosophies). Then look at one or two projects that involve software development and look at what the challenges are that needed to be tackled, and how cooperation within and between teems, with vendors, libraries, users, and API consumers happens. Look at incentive structures for different people in different constructs (FOSS enthusiast after work; PhD cand; software employee in car industry; employee at large software company; manager there), @mhoye and the social struggles they have. Is it time pressure? Money? Disconnect from management? Appreciation? Disconnect from the purpose of the software? I'd probably also take a lecture to talk about quantifiable effects of lack of gender equality, and diversity (if you can find an expert at a different faculty, invite them?). Talk about how FOSS projects survive differently than companies. Talk them through a contribution to someone else's (or another team's) codebase in both cases. EOF @mhoye I just realized that "first semester" means that students still think they'll be developing the next big AAAA game alone; you might want to very brutally clean up that misconception. @mhoye this guy if he agrees: https://leanpub.com/u/laurentbossavit Check his book, If you didn't read it. Great stuff. @mhoye I suspect you're looking for things that are more article length, but Biella Coleman's Coding Freedom is A+: https://press.princeton.edu/books/paperback/9780691144610/coding-freedom  @mhoye papers like "worse is better" come to mind or Gabriel's excellent reflection on what later turned ibto design pattern, the origin papers of agile (eg the crysler paper), manifests like extreme programming, make them watch the douglas crockford javascript talk series, a couple of famous rants don't hurt either. @mhoye I would teach them to design software for people, not bludgeon people into learning software. My bestvprogramming prof said: "Language doesn't belong to you. You can only borrow it from the person you're speaking to." Figure out the UI needs FIRST and design the software to suit, or you will have frustrated unhappy users. You're not smarter than your users if you refuse to speak THEIR language. So many programmers think they can just SHOUT LOUDER. No.  @praxeology @mhoye @GIFmodel @Femke Failed projects sometimes arise from developers who thought they knew better than the business.  oh, everything that @praxeology said, plus: The Boy Kings - Katharine Losse  @praxeology @mhoye @GIFmodel @Femke seconding Ursula Franklin, I think she would be a wonderful lens to teach the whole thing thru Get a bunch of grey beards from various local companies, including freelancers etc to talk about their careers. @mhoye id start with the history of labor in computing from women in basements to foss and xp/agile @mhoye I would include the RFC process of the IEFT. Engineers collaborating publicly and intentionally on proposed standards that live or die based on experience gained through real implementations. Lots of proposals. As they are public, anyone can implement. Only RFCs with multiple successful implementations survive long term. The result is broad inter-operability of networked systems. @mhoye The importance of moderation tools and user-to-user access controls, with a quick profile of various threat actors. State, spam, griefing, mob stalking, individual stalking without everyday access, abusive close contact with everyday access. http://wiki.dwscoalition.org/wiki/index.php/Design_Personas#Anti-Personas   @mhoye I would love that course to focus the first ⅓ on the names of all the contributors to the codebases run in computer shops from 1975 to the present, then in the second ⅓ fan that out into where the money came from, then in the final ⅓ the tooling currently listed in job openings with a breakdown of which companies foot the bill for the ongoing maintenance and development of said tooling. Really drive the message home what problems computing is currently funded to address. @mhoye This is a very thought provoking question. Best way I can think of is organizing it historically/chronologically? Talk about all the major inputs/forcing functions to the culture (original huge government contracts + academia, then big business IBM, all the way to VC techbro). Shape it in the context of "why" we are where we are. @mhoye When I taught a "Science in Society" class for engineers, I used David Nye's "Technology Matters" as an accessible overview for critically thinking about the tech they use. Rushkoff's "Program or be Programmed" could fill a similar role. It's less about anything specific regarding tech, and more about how it is used and engaged with. Programming in ten weeks: how many students? If there are 10+ , you give each student a significant aspect of software and more importantly, of data. You pick out the ten aspects.  @mhoye Lots of them learn the early parts of the SDLC in school, but it's much harder to get exposed to the later parts: deployment, maintenance, monitoring, ongoing security. These are driven by culture and hard-won experience from industry, responding to various failures from running software at scale and teams over time. Teach why DevOps exists, why Agile, etc.  @mhoye I’ll do that by practicing (making web things together) and discussing. That is what I do with my 1st year students at ENSAD paris. I can give them English readings, but they will not read them. @mhoye oh, one more thing, since I agree with people replying that doing something hands-on is important: One exercise that Rodrigo does in "Digital Anthropology" is to have students read Turing's "Computing Machinery and Intelligence" and then to have them play the imitation game. It's really effective! @jboy @mhoye hey @inquiline, you're mentioned in this thread but there might also be some other stuff relevant to your recent post seeking fresh lit on computing ... @mhoye A lot of programming culture still seems to be rooted in the Good Old Days, when programmers wore t-shirts and sneakers where everyone else wore suits, and spoke in a mixture of technical terminology and slang from the Hacker's Dictionary. When programming was just coding, and formalised project management processes were new. Technology experts may love innovation, but they are as susceptible to rose-tinted nostalgia as anyone. Might have to disillusion a few old-school nerds. @mhoye whoops, meant there's more existing research on "social media" (don't like that term....)  @mhoye Ooof, this is very close to what I studied at university! I would *not* teach coding and related architecture or methodology. They can learn that elsewhere. Instead, you could explore why the tech world is the way it is. Looms, punch cards, Babbage/Lovelace. @JamesGleick ’s “The Information”. Shannon and Turing for compsci theory. Lessig’s “Code is Law” + an intro to FOSS for practice. Top it off with @timnitGebru ’s stochastic parrots.  @mhoye Wow nobody mentioned |
Gregory's Server
@mhoye System Design, Statistics, White Boarding, and starting with design first. Happy to discuss more, I've been teaching workshops to people learning locally. Happy to chat more.