HtDP Courses and Colleagues

Apr 9, 2011

So, you are considering a freshman course based on HtDP or HtDP/2e. Then consider yourself brave.

To understand my point, let me explain a little psychological insight first. Our colleagues “know” how to program and they “know” how to teach it. They learned it some 30 or 20 or even just 10 years ago. Here is how you do it. You show the kids how to print "hello world" and you show them how to read a line or a number from a file; you declare some variables and arrays; you write some loops, while or for preferably; you package things up into procedures and methods; and if you want to be fancy, you can always modularize your program with classes. And that’s all there is to it.

Everything else is software engineering, and we don’t need to concern ourselves with that in a first course. They learned it that way, they programmed a bit that way, and we should teach it that way. What’s the big deal? Sure enough, we could freshen up on the syntax and the I/O methods du jour but that’s all that’s needed. And once students know those basics, your colleagues can teach them the important things: big Oh, machine architecture, lin alg for graphics, probability for AI, etc. This description is a caricature but it isn’t that far off.

Truth is too few academics and colleagues program much (other than in LaTeX) or participate in the construction of large systems (other than via thought experiments). And they think that if they could learn programming in the above-mentioned fashion, and if it was enough to get them as far they got, it is good enough for freshmen in 2011. Never mind that our understanding of programming and proper program design has evolved and that we really need to change how and what we teach.

Now let’s face it, reality is our colleagues are too busy to learn our new way of programming, figure out an approach that calls for whole-sale adoption not just some gradual changes. Our colleagues teach their own courses, they have grants to chase, papers to push out the door, families to take care of. We can’t impose another large task on them. We must teach students properly and we must teach students how to “talk” to our colleagues. Put differently, it is our task to prepare our students so that they can also program the way our colleagues expect them to program, and the students need this capability any way, because they will end up working in companies where most people learned to program the old way.

The problem is that you cannot teach everything in one course. Furthermore you probably can’t just teach it all by yourself without any help. Getting someone else involved also has the advantage of widening the “basis of appreciation” for the HtDP style approach to teaching programming.

At a regular university with a reasonably standard four-year curriculum and decent colleagues, you need two semesters and one colleague to get started. Take on the first semester and drill basic design skills until they become second nature in the teaching languages. Ideally have your colleague teach this course with you; there is no better way of learning what HtDP is about than teaching it with someone else. Take the second semester (1) to show students how the design skills apply to whatever language your department finds amenable and (2) to connect design with basic algorithms, standard libraries, and conventional programming techniques (while, for, and arrays über alles). It is probably best to let your colleague lead the second semester.

For the generalization of students’ design skills to other languages, consider using How to Design Classes. It demonstrates—slowly and carefully—how design applies to Java. If you choose How to Design Classes, Shriram Krishnamurthi and Kathi Fisler’s experience suggests to skip right to tree-structured data once the basics of classes and interfaces have been covered. It is also possible to teach design recipes in Python and JavaScript.

For the adaptation of the design skills to conventional programming, you will need four to six weeks at the end of second semester. The goal is to make the students “buzzword compliant” for their first co-op or internship:

• The students need to know how to read from a file and they may have to know how to tokenize a line (regular expressions, tokenizers). Yes, we know that this is really a form of parsing but our colleagues don’t seem to appreciate this connection.

• The students need to know how to write to a file.

• While the design part of the second semester can easily introduce applicative and imperative versions of stacks, queues and various search trees, it is now time to show students some modern data structures, especially what Java calls vectors, hashes, and maps, but also associative tables.

• Naturally the students need to know for and while loops to process such indexed data structures.

• Lastly, you may wish to show your students some rudimentary GUI programming using “native” libraries. This part is optional but students might find this useful.

As TeachScheme! and co-op explains, this strategy worked really well at Northeastern. The students’ programming skills improved dramatically, and our co-op department reports on these improvements on a regular basis. Our colleagues’ appreciation of the students’ programming skills has grown dramatically. Sure, we hear some grumbling on occasions, but they are relatively minor and they quickly die down when we offer to hand over the course.

Your colleagues may differ from those at Northeastern. Your students may differ. So your mileage may differ but ensuring a connection to the conventional downstream curriculum is almost always critical.