More objective
December 11, 2013 at 8:34 PM by Dr. Drang
I ended last night’s post with this:
I assume that… programmers who write scripts this same way have been taught to do so. They haven’t been served well by their teachers. They’d be more productive—and we’d be getting the benefit of their talents—if they’d been taught how to design programs that fit the problem to be solved.
Tonight I want to revisit this idea and argue the opposite side. Or maybe argue both sides; we’ll see how it goes.
In engineering,1 there is a recognition that some things are best learned in a university environment and some are best learned “in the field.” Your engineering education isn’t considered complete when you get your diploma. This is reflected in how we license professional engineers. You cannot get a PE license straight out of college, you’re not even allowed to take the PE exam then. First, you have to go out and get some experience, presumably learning those things about the practice of engineering that aren’t suited to classroom instruction. Only then are you allowed to sit for the exam and get your license. It’s analogous to physicians going through a residency after getting their medical degrees.
Engineering education, then, focuses on the things it can do well, the eternal verities of the profession. In mechanical engineering, for example, those eternal verities are statics and dynamics, mechanics and properties of materials, fluid mechanics, thermodynamics, heat transfer, and control theory. One of my colleagues back when I was teaching was fond of saying that the basis of the mechanical engineering curriculum was “everything you need to know to build a steam engine.” He was right; luckily, those same topics are applicable across a wide variety of machine design problems.
I don’t pretend to know the eternal verities of computer science, but I would guess that some of them are algorithms, data structures, and abstraction. These are, I think, good topics for the classroom. It’s possible, though, that the kind of overall program design I was talking about at the end of last night’s post isn’t well suited to the university environment. Maybe that’s the sort of thing that’s best learned only “in the field.” If so, my complaint about CS teachers was unwarranted.
However…
Engineering undergraduates are typically required to take a capstone design course their senior year. The idea is to have them synthesize what they’ve learned in the previous three years and apply it toward a design project that is as close to a “real world” experience as possible. They are also expected to confront problems they may not have been taught about in class: machining tolerances, material supply constraints, costs, schedules, human factors, and so on. These projects are intended to get a start on the professional seasoning that turns students into good engineers.
A CS version of this capstone course is what I was thinking about when I talked about teaching programmers how to design programs. I’ve looked at the requirements for a handful of CS programs, and the results are mixed; some schools require such a course, some don’t, and some require it only for certain tracks within CS. I know it’s always hard to shoehorn another course into an already packed curriculum, but I think it’d be valuable for everyone to have a course covering practical matters like language and library choice, programming style, and division of labor among programmers.
-
Traditional engineering, not programming. ↩
