Open Source Projects Could Augment CS Curricula
Everyone is talking about Joel Spolsky, especially with his latest article.
Many appreciate what he has to say, but then again, he is basically articulating what we all know, and plenty figure that maybe his writing is no longer fresh, and he is just cranking out articles in order to shill his warez:
“This might be a neat opportunity to use Scrum. Once a week, the team gets together, in person or virtually, and reviews the previous week’s work. Then they decide which features and tasks to do over the next week. FogBugz would work great for tracking this . . .”
My position is that most stuff we read is mediocre, and Joel at least writes well, and Joel wears his ulterior motives on his sleeve, so when he starts figuring FogBugz can cure what ails CS curricula, I just figure “and now a word from our sponsors” and my brain hits the fast-forward button.
I think Tom actually has the best reaction to the issue Joel brings up, in that he adds that different people have different learning methods:
We all know there are students that are “visual learners”, “audio learners” and “kinesthetic” learners.
We all know what? Okay, yeah, and “everyone” is talking about this, right? Anyway, Tom, like me, is a learning-by-doing kind of guy who didn’t always “get” the formal CS curriculum:
When I took my undergraduate class on software engineering methodology I felt it was useless because I couldn’t see the point of most of what I was being taught. Most of my programming had been done solo or on a small team. I could not take seriously the problems that were being “fixed” by the software methodologies discussed in our lectures. “Code size estimation? Bah! Impossible, so why even try!”
In my CS days, the bits I enjoyed most were the learning-by-doing: compiling my first C program, bending my mind around recursion and functional programming to complete assignments in MIT Scheme, implementing a virtual spanning tree, and coming up on my own with the idea of a finite-state automaton to parse NWS weather forecasts. (Okay, that wasn’t a CS assignment and I didn’t know how to talk to girls.)
The parts where I fell completely flat were the theoretical classes where we considered bizarre hypothetical problems that didn’t make sense, using Greek letters that didn’t seem to have anything to do with reality. One day my ECE roommate asked how, as a CS major, I would go about sorting one million integers. My response was “why would you want to sort one million integers?” Later I slept through multiple lectures where the best methods of sorting integers were discussed at length. I skimmed the slides so I know that Quicksort performs well and in-place, but that Bubble Sort may work better if your data is mostly sorted, so in my mind that just means that if anybody asks how you would sort one million integers, the correct answer is to ask some questions as to why they need to sort one million integers.
Uh, yeah. Anyway, what was I nattering on about? Joel’s schtick is that CS students aren’t taught to manage large, complex, “real world” projects with lots of moving pieces. CS mostly focuses on the “interesting 10%” like how you would sort a million integers and skips over the boring 90% of hard work like implementing the interface for the customer to provide their million integers and retrieve the results. And Mark Dennehy’s reaction was “of course we focus on the interesting ten percent: the other 90% is constantly changing and best learned on the job!”
But, addressing the “how do you tackle big projects” thing, I think Joel has a point. And his point isn’t new. The point is extra-curricular activity.
Whether you’re a visual learner or whatever, the biggest secret to learning things is to find the thing that you are studying interesting. The very best computer programmers are all fucking fascinated by the challenge of getting the computers to do things within given parameters. Computer programming is fun because when you get down to it, it is a lot like computer games: a person at the interface banging away until they get their dopamine fix by either beating the level boss or getting the damn thing to compile and spit out the correct result.
Well, that is for the learning-by-doing types. Some computer programmers get their jollies by trying to fathom a new and novel method of sorting one million integers. Whatever floats their boat, I guess.
Anyway, long story short, I’m thinking the learning-by-doing types tend to get a little queasy after a few CS theory classes and end up majoring in English in order to score a bachelors degree, but they keep tinkering with the computers along the way, and end up, like Tom and me, as systems administrators, figuring out the best way to keep 1,000 computers running in order to make it possible to sort billions of objects with map-reduce algorithms in constant time.
Oh yeah, and that I agree with Joel that motivated CS students ought to find non-class projects that they are passionate about, and thereby gain chances to collaborate with others on the sort of “real world” challenges that they are likely to face in their professional careers. Back at Illinois the ACM played a big role in this. I myself did some time apprenticing at NCSA and at an ISP, and the big win these days it would seem are the oodles of Open Source projects ready to put interested volunteers to work. And that’s why Google’s “Summer of Code” just sounds like a fantastically great idea.
