In a comment on Mark Guzdial’s blog post Pushback in California on Computing in Schools, “lizaloop” wrote
2. While I support the effort to bring programming into schools I’d like to see us also emphasize the concept of each person taking charge of his or her own learning. Because programming languages change so rapidly anyone who intends to do serious coding will have to repeat the learning process over and over. Our introductory CS classes need to focus more on “learning how to learn” than on the specifics of any one coding language.
While it is certainly true that programing languages go in and out of fashion (where are the COBOL programmers of my youth now?), and it is also true that people need to keep learning if they want to remain in any technical field for long, that doesn’t mean that intro CS courses should give up on teaching specifics and instead tackle the nebulous goal of “learning how to learn”.
In fact, one of the things that distinguishes computer programming from many other courses of study is that you must learn the specifics of the programming language and tools you are using if you are to get anything done. “Big picture” thinking does not get programs written. It does you no good to “learn how to learn”, if you then don’t learn any of the details.
One of the major things that students new to computer programming (and to other engineering fields) need to learn is that details matter. The specifics of the computer programming language they are learning matter—not forever, since they might never use that particular programming language again—but while they are doing what they are doing right now, the details matter. That is an enduring, transferable lesson, but it depends on having a course in which the specifics of the coding language are viewed as important.
Of course, this does not mean that the teacher has to spend a lot of time on the details—the compiler or interpreter will make it abundantly clear to the students that details matter. But the teacher can strengthen or weaken that lesson by their own example and by their grading. Teachers who only do sloppy pseudocode on the board, never filling in the missing details or correcting mistakes, will convey the impression that the details are unimportant. Teachers who don’t mark down sign errors, punctuation errors, and off-by-one errors in quiz or exam answers also give the impression that “close is good enough”, which is emphatically not the case in real programming. Teachers who never read their students’ programs, but only do crude I/O testing to grade programs, will give the impression that documentation doesn’t matter.
On the other hand, teachers who spend all their time fussing over semicolons and never talking about the bigger ideas of algorithms, data structures, problem decomposition, and program documentation will produce low-quality copy editors, not programmers. One reason I like Python as a pedagogic language is that the syntax is simpler than many other languages, so that I can get the details right without having to spend so much time explaining the details (and the students can spend more time on more interesting debugging than chasing down punctuation errors).
But I’m not trying to dump on lizaloop’s ideas entirely. Computer programming courses are a good place to teach students to “learn how to learn”, though not by ignoring the specifics and following some sort of touchy-feely metacognition curriculum. Indeed, it is because of the specific details that students must master to get anything done that programming is such a good subject for learning how to learn.
Those specifics are essential to the task at hand (not some nebulous future need that is all most math or science classes manage), but they are easily looked up in on-line documentation with generic Google searches. Try googling things like python reverse string, HTML color, or c++ function pointer to see how easy it is to get online tutorials and documentation on specific details.
It is completely reasonable for a teacher to give students concepts and keywords, but expect them to look up some of the details for themselves. For example, a teacher might explain RGB color space and how colors are often encoded as three one-byte numbers in hexadecimal format, but not give any specific color codes, expecting students to find the codes they need either by experimentation or by on-line search.
In the approach I’m suggesting, the students are still focused on the details of the coding language, but they are also learning how to learn (at least at the lowest level of learning how to look up specific facts).
Teaching students how to learn more complex concepts on their own (like how to choose which color space to work in) is probably a forlorn hope, but getting them to learn to look up specific facts (like how to transform from HSV color space to RGB color space) and low-level details (like HTML color codes or how to reverse a string in Python) is certainly a reasonable expectation for an intro CS course.