Gas station without pumps

2014 September 25

Details matter

Filed under: Uncategorized — gasstationwithoutpumps @ 11:57
Tags: , ,

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.

6 Comments »

  1. […] in response to a comment on Mark’s most recent blog (which is below that).  Another blogger, Gas Station Without Pumps, has made further additions to the multilog. Do weigh in with your own point of […]

    Pingback by Pushback in California on Computing in Schools | HCLE Virtual Museum – the blog — 2014 September 25 @ 14:45 | Reply

  2. I agree completely about the details. In fact, one of the reasons I like to teach programming is because it is the computer that is too stupid to interpret sloppy code rather than me, the human teacher, who is refusing to guess what the student means to say. People can read around grammar and punctuation errors. Most computers can’t. That lesson can be gotten across fairly quickly, in far less than a school semester. But, alas, some of us are so impulsive that we will never become accomplished coders no matter how many courses we take in various coding languages. Once we have discovered that we are not programmer material there are a lot of other topics we need to digest about the role of computers and computing in our society. My concern is that by emphasizing ‘Computer Science’ instead of ‘Computer Literacy’ those who are frustrated by coding may miss those other lessons. If we ask everyone to take ‘Computer Literacy’ (or ‘Computing in Society’ if you prefer) with introductory programming as a component of that course, everyone will get what they need to be informed 21st century citizens (well, at least about computing). If we characterize these courses as ‘Computer Science’ or ‘Programming in XYZ’ we are likely to lose a significant portion of students who really do need to understand the importance of details, among other things.

    Comment by lizaloop — 2014 September 25 @ 15:11 | Reply

  3. I am a big advocate of the “learn how to learn” concept but I try to be realistic about it. My programming classes are in the “this is how to learn Java” (or whatever) direction and not “here is Java”. I am not good enough of a programming teacher to teach all the popular languages but I am a good enough teacher that I can get the kids learning the language and learning the teaching resources. If all universities and businesses used only one language then I would teach the kids all the gruesome details of that language. But as it is the kids have to be able to shift gears quickly so they can pick up a language they may have never seen before. Hence the “learn how to learn” approach. The trick is to give them some details to hang their hat on. Nebulous is a bad thing with high school kids.

    Comment by gflint — 2014 September 26 @ 09:56 | Reply

  4. I would say that the essential point you are making is that they are learning a language, and details (even gruesome details) really matter when learning a language.

    If you learn one programming language completely and well, you can learn almost any other programming language comparatively easily. It helps immensely if you learn a modern strong-type object oriented language (e.g. Java or Ada) first, because there will be fewer bad habits to break, but learning a second or third programming language is easy compared to learning a spoken or written foreign language. (COBOL might be an exception to that statement about ease of moving to a new language, but I can’t say because it and Python are among the few I haven’t used.)

    I agree that learning how to find the details is crucial along with interpreting what you find. Learning how to read a language manual or gronk what you find on the internets or interpret compiler error messages is 90% of the battle.

    My single bit of teaching advice is that the biggest challenge faced when teaching programming must be that the students taking such a class have no idea whatsoever about algorithms or problem decomposition. Lack of problem solving experience, especially in the sense of problem decomposition, is a huge problem when teaching physics so I would recommend sticking very close to what they might know from math. (Many are not even taught a specific algorithm for long division or multiplication if they get unluckily placed in a particular group of K-6 curricula, so even that concept might be a mystery to many students.) Anything else will require paying a lot of attention to just being able to write down a description telling a complete idiot how to do something like dry dishes.

    Comment by CCPhysicist — 2014 September 28 @ 13:33 | Reply

    • Details matter, but not just “when learning a language”. They matter in every engineering design project. So this is one place where I expect to see transference from teaching programming to teaching other engineering disciplines—as long as students get the message that details matter, and not the message that “you twiddle with things until the compiler shuts up”.

      Comment by gasstationwithoutpumps — 2014 September 30 @ 18:38 | Reply

      • Oh, absolutely. That approach to programming is as bad as the “twiddle things until the answer matches what is in the back of the book” approach to doing physics or math problems. What I liked about comment 2 is the insight that they take the computer’s insistence on clarity more seriously than they do faculty.

        Comment by CCPhysicist — 2014 October 3 @ 22:00 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: