I'm back from the largest CS education conference in the world (1184 attendees this year), and... I think I've gotten sleep now. There are some more focused notes coming from specific sessions and conversations on opensource.com/education, but there were some random snippets that didn't seem poised for a full article but that I didn't want to lose - here they are, from my notebook straight to this blog.

One thing that struck me, once again, is how busy teachers are. The day-to-day of shepherding students leaves little time for staying atop new technological developments or finding and trying out communities and support groups for unfamiliar ideas like "open source." Sometimes I feel like the curriculum of POSSE is almost extraneous - after all, these folks are smart and could learn everything we're teaching them on their own. What we're actually doing is giving professors time and keeping their minds on the general idea of open source for multiple (ideally) uninterrupted days in a row. Time to think about open source, time to let new complex ideas sink in, time they don't normally get in the rush and bustle of it all.

I talked with Matt Jadud of Allegheny College on the last day of the conference about this phenomenon; he pointed out that teachers must, of necessity, be in many different communities at once - their discipline, their school, their town, their department - and that this massive bridging means that faculty need to know advance plans of the groups they're working with so they can be nimble and opportunistic in crossing between them all when the moment arises. This is similar to how a Linux distribution needs to set up hard deadlines for feature freezes well in advance of the alpha because it relies on so many upstreams with different production schedules. In contrast, a FOSS hacker might be involved deeply in one or two projects at any given point in time. Perhaps this has something to do with the timelines of academics as compared to open source.

Another illuminating conversation: Steve Huss-Lederman from Beloit College, who described his school's usage of Eclipse throughout their CS program. The Java-based IDE is a steep learning curve for new students to climb, but once they're used to it, plenty of power is integrated via plugins for nearly all their classes. (He described UML diagram integration with particular relish.) If we focus on building experiences rather than isolated classes when teaching open source, we can start looking at these sorts of longer-term tools that take more time but have a bigger payoff. We just need to make sure students see it the same way; I could imagine being the disgruntled first-year moaning about why I couldn't use my favorite minimalist programming environment for basic stuff, and kludging my setup to do exactly that until junior year when I suddenly discover that I've reached the limitations of good ol' vim.

Steve was also the one who asked how to keep student project failures (which inevitably happen - it's part of the learning experience) from damaging an institution's reputation. Stormy Peters from Mozilla replied that only a repeated pattern of failure would hurt; expectation-settings at the beginning would make it clear to participants that the students are using the project as a learning experience. Western New England College's CS chair, Heidi Ellis, added that scouting project communities beforehand was vital, and that "it's a risky approach... but the benefits are really, really worth it."

Another thing I learned from Heidi was the importance of external community feedback - if a professor says something, it'll occasionally go in one ear and out the other for students. If a community member says it, though, it's suddenly real. I joked that my move to graduate school in the fall would effectively strip me of "magical realness powers." (My team at Red Hat has vowed that if this happens, they will  throw things at the ivory tower until I poke my head out again. I love my team.)

Another quote I wrote down was Trinity's Ralph Morelli - "Do you think it's an accident that we're all from small schools?" Sure enough, in the entire (full) room at the HFOSS Symposium, there were perhaps... 3 professors from institutions with more than 10,000 students.

Listening to Steve Huss-Lederman and Karl Wurst from Worcester State College describe graduation requirements as directed acyclic graphs - and swap stories about how they'd generated actual graph diagrams for their programs - cracked me up, although it has absolutely nothing to do with open source.

There was some discussion on K-12 CS education, though most of the attendees were teaching at the college level. We head about CEUs, "continuing education units," which K-12 teachers are required to
take a certain number of in order to keep their teaching certifications.
We should figure out what it takes to make various sorts of open source
experiences count for CEUs - perhaps a modified POSSE curriculum would
be appropriate.

One insight from the K-12 crowd I thought was great was how they answered the question "how do we get more quality CS graduates?" Well, they reasoned, we first need more quality CS teachers. Therefore:

  1. Encourage CS students to go into teaching.
  2. Encourage high school students who want to major in education to study CS first.

I would not have thought of this, although it sounds obvious in retrospect. When folks walk up to an engineering undergrad, you expect them to say things like "hey, you're really smart... you should work for <prestigious-company> when you graduate." Not so much "hey, you're really smart... you should go into teaching."

"CS in education" is a hot topic right now across the USA; the ACM successfully lobbied Washington to include CS in the definition of STEM, and the NSF is also doing a huge push for getting CS into the American K-12 curriculum. Both of these groups care less about open source per se, but if we can make open source a part of how CS gets taught, then we win.

There was talk about scaffolding: with the current system of college math, it's easy to look at a student coming out of high school and go "ah, you took algebra and geometry and precalculus - I know exactly what you know and what you don't - proceed to calculus now." There's a standard notion of what each of these high school classes means. Computing has no such standardization; one high school's "introduction to programming" might match up with one college's entry requirements but not another's. I'll note that the way this was presented on the panel made it sound like increasing standardization was - of course! - the goal we should be striving towards - but I'm not so sure myself - it's a tradeoff, and education systems tend to default towards more structure - presumably because they can get more students through the system that way.

This exhausts my notebook o' notes. What did others take away from SIGCSE?