Ultracrepidarian

Yesterday I wrote about using a lesson on how to run a meeting to get undergrad software engineers to think about the way that “who interrupts who” reflects and reveals social status within groups. I really want to create a similar lesson about grading—if students are working in teams, then:

• How do performance evaluations typically work in tech companies?

• How is grading in undergrad courses similar and different?

• How much say should teams have in how they’re graded, or should every team be graded the same way? (This seems like a good moment to introduce some ideas from Scott’s Seeing Like a State.)

• How should individual team members be graded given that the instructor can’t watch them all 24/7 to see who’s actually doing what?

• (How) can we stop people from gaming the grading system?

• How do we give fair credit for “invisible work”? Conversely, (how) can we design a system that doesn’t over-score some kinds of work just because it’s more visible?

• Who gets to decide, and why them?

What’s stopping me is that I don’t know nearly enough about the research on this to start. Without someone who’s familiar with the literature as a writing partner, what I produce will almost certainly be yet another ultracrepidarian middle-aged guy saying, “It seems obvious to me that…” This is another illustration of why these lessons will be hard to write: programmers like me don’t know the research, and the people who do mostly don’t know how to talk to programmers.