As a new school year starts to roll around I naturally pay a little more attention to articles about undergraduate education. I'm once again teaching a one-term course on Object Oriented Design and UML at Trent University in Peterborough. This is of course just one piece of the curriculum. Trent is an interdisciplinary place and its graduates are expected to understand the concepts that underpin what they're learning. In fact this is what I see as the main difference between those with a university education and those without (though there are exceptions on both sides.) It's one thing to learn, perhaps by rote, the steps required to make a certain kind of application, and it's another to understand what you are doing and why. The latter kind of person generally finds it easier and easier to learn new things, connecting them to things already known, while the former finds it harder and harder as a mass of seemingly-unconnected facts moil around in an overly-crammed head that feels ready to explode.
I approve of valuing concepts over specific how-to's. It's hard work keeping up with the very latest technology when all you're doing is using it. It's even harder when you're also working on concepts and trying to teach. I don't expect a university to teach students how to use a specific user interface framework (MFC, Winforms, WPF, whatever) -- I expect it to teach them user interface concepts, illustrated with some framework the prof happens to know that's generally available. The students can then learn a variety of UI frameworks over their careers. But that doesn't mean I approve of all the ways in which programming as part of undergraduate education varies from programming in real life. Two specific variations I have a problem with are team size and problem size.
In real life, it's rare to work all alone, all the more so when you've only just graduated. Most university computer science grads will join a team of 2-10 developers reporting to a lead of some sort, with various people from QA, user reps, the business people and so on having various positions of semi-authority, semi-teammate in relation to them. Yet undergrads are generally expected to work alone on all projects and never discuss them with anyone until handing them in.
In real life, problems are not well specified, certainly not as tightly as undergrad assignments are. Most importantly, in real life user input is bizarrely ill formed. Users type letters where numbers belong, leave mandatory fields blank, even deliberately construct complicated bad input as part of hacking attempts. Yet most undergrad assignments do little or no input validation or error handling unless those are the point of the assignment. And of course, most undergrad assignments can be completed by an inexperienced programmer working alone a few hours a week (10 at most) in a week or two while most real problems take weeks and months of work by one or more dedicated resources to produce even a preliminary solution.
Trent (and I presume most other universities) addresses these issues with a fourth year course in which a team of students works on a real problem for an outside entity - usually a local firm or charity. They must gather requirements, code, test and implement a solution, and present to their peers and professors a summary of the project. Some students benefit immensely from this, though most take on far too big a challenge and struggle to complete it.
My contribution is to point out to my students where things are being simplified for them, where things would be vastly different in real life. Undergraduate courses simply cannot be the same as on the job training, and I don't want them to be. I want my students to be learning concepts and underpinnings as much as language syntax and how to work particular tools. But I want them to understand that when they start to put all this to use, things will feel very different than they did during class time. An assignment from your boss and an assignment from me are very different. (I've blogged before that in real life,
you don't get 7/10, you have to keep doing it until it is right.)
I don't have all the answers. Lots of people muse about this stuff.
Here's the inventor of C++ on the same issues. Easy to complain, hard to do anything about it, but we can all do our bit.
Kate