Seeing Like a Student

Earlier this month I posted that I don’t know how to reach the unconverted, i.e., I don’t know how to persuade Frank—a 20-something straight white/Asian male programmer who has grown up watching toxic bullshit on YouTube—to care about ethics, equity, and social responsibility rather than dismissing the topics as “woke”. The only idea I’ve had so far that I think has any chance of getting past Frank’s defenses is to embed ideas that matter in an undergrad course that is ostensibly about building software in teams. It’s still more a concept than a plan, but I think it’s coming into focus.

First, the “Intro to Software Engineering” courses I’ve looked at generally present a mixture of technology (“here’s how to use Git branches when working with other people”) and working practices (“here’s how to gather requirements from stakeholders”). The former is useful, but is generally presented as value-neutral: for example, I’ve yet to see a course that explicitly says, “Whoever decides on how tickets are allocated to team members is effectively in charge of the team.” The material on working practices, on the other hand, mostly bounces off: it’s impractical for instructors to check whether students actually pair programmed or not, so under pressure from several other courses (whose instructors don’t talk to each other about deadlines) students often optimize by doing what they need to while saying what they’re supposed to.

So here’s a vague sketch of what I’d like to try. I think the first lesson of a course on building software together ought to be about how to run a bloody meeting. I think the second should be about grading—more specifically, about why it’s hard to grade work that is done in a group and out of sight of the grader. Should everyone on the team get the same grade? If not, who decides who gets credit and who doesn’t? And if teams are working on different projects, should their grading schemes be the same or not?

This is the point where I think we could smuggle in some big ideas. Scott’s landmark book Seeing Like a State argued that big organizations prefer uniformity over productivity, i.e., they would rather have everyone work the same way (so that the center can control things), even if it means doing less well overall, than try to manage chaos. The natural response is to say that teams should do what they think best, but “let people decide for themselves” shades pretty quickly into the “states’ rights” arguments that were used to defend segregation.

I think the second lesson of an undergrad software engineering class is an opportunity to walk through the arguments on both sides in a way that Frank will actually pay attention to. Going back to the first lesson on meetings, I think half of it should be devoted to how teams make decisions, which is an opportunity to bring in ideas from Freeman’s “The Tyranny of Structurelessness”.

I’m now looking at my old notes on building tech together through this lens. Many software engineering classes talk about entrepreneurship, for example, but only present Silicon Valley’s “build fast and cash out” model. I think students should also be introduced to Burlingham’s Small Giants and to the rich history of co-ops and community-owned companies, and that instructors should then spend some time explaining why and how banks and venture capitalists discourage people from thinking about those options. It’s pedagogically defensible—school’s job is to broaden people’s minds—and I think it will tickle Frank’s craving to feel like he understands the world better than other people.

The challenge is to match things that Frank and his instructors believe belong in that course with bigger ideas. Can a lesson on intellectual property segue into a discussion of regulatory capture, or will that feel clumsy and obvious? How about a discussion of roles in teams? Can that be a pretext for talking about invisible work and/or preparatory privilege? If so, can the transition from one to the other be made seamless enough to seem inevitable? I don’t yet know, but I’d welcome your thoughts.