Do We Need a New Pascal?

I just read a short article about “Why Johnny Can’t Code” which, in a nutshell, asks what an appropriate language for beginners is. Once upon a time, it was Pascal. Lots of people liked Pascal, and many still do. They don’t like the monstrosity of C++ or Java or C#. They’ve concluded the object-oriented programming is too tough to teach.

Now, I have a bias. Since I taught at the college level, I think of computer science education at that level. Given the title of my blog, however, I should really consider programming at high school and even earlier. How do we teach programmers to kids? Many kids learn to program using a language called Logo. Logo was pretty much a cursor, which you gave commands to, and it drew lines. It was visual, which gave plenty of feedback to the programmer. It didn’t do anything particularly useful, but the ideas behind logo (looping, conditions) are valuable to programmers.

These days, people want programming languages that allow users to do something interactive with the user, preferably of a graphical nature. This could be a GUI, but more likely is a game, or some interactive world.

Why do teachers want a new Pascal? Even at the college level? What’s wrong with C++ or Java?

Many programming teachers learned an imperative programming language like C or Pascal. It’s taken quite a few years for teachers to learn how to think in object oriented terms.

I’ll relate a story. I was teaching with someone who was bright (at least, enough to get a Ph.D.), but clearly her background was imperative programming. How so? She developed a project, where she wanted the students to break this complex task into three separate subtasks. Each of those subtasks were public methods. They had to be called in sequence. Call subtask A, then subtask B, then subtask C.

It was a good idea to break down the tasks into subtasks. It’s one of the oldest teaching ideas in programming: stepwise refinement (seems like we’ve always given fancy names to simple ideas). But it’s an awful idea in object oriented programming. In general, any class that requires you to sequence method calls is problematic. It forces an order that’s hard to check for in the program. For example, even the common programming idiom of opening and closing a file is a pain.

Ideally, you want the constructor to open a file, and the destructor to close it. But you may not want to open the file right away. Simple. Create two classes. One class, when it calls open() will return a second object. That object, when it gets destructed, will close the file.

But my point that a relatively bright person still thought imperatively, not in object-oriented terms, even though she was familiar with C++ syntax.

It’s been argued that it’s too hard to teach in a “objects first” approach. What is objects first? Many people teach C++ by teaching C first. Learn how to program imperatively, then learn how to program using good OO principles. The reasoning behind this was obvious, yet flawed. C++ came from C, thus object oriented programming comes from imperative programming. As big an authority as Bjarne Stroustrup argues that you can learn C++ directly.

Having said that, it’s tough to say whether Bjarne is right. After all, Bjarne’s a bright fellow, and we’re talking about teaching programming to the masses. It may even be that you can’t teach programming to the masses. It’s like teaching math to the masses. It may be that programming is at least as hard to learn as algebra, and many an American, despite taking algebra, are barely competent, years later, to do algebra.

I don’t know if teaching objects first would work or not. Many do try, and have the benefit that those who don’t get it can seek other majors. I’d like to try it myself at some point, just to see what would happen.

The reason there are objects-first advocates is Java. Java makes it very painful to write in a C-like style. While Java has a main() method, this is the primary remnant of C/C++. To write in a C-like style, you’d have to teach static methods and static variables early on.

Then, once you do that, you’d have to tell students not to use static methods and static variables, because no sane Java programmer codes in this style. Rather than teach this style, then have to convince students this is nuts, you have to teach objects early on. Even advocates of objects later still have to deal with objects really early on, as there’s objects everywhere (Strings are objects, for heaven’s sake).

One reason for teaching Java or C++ in college is that it builds a skill that’s directly usable in the real world. Well, almost. Java is evolving. They just came out with Java 1.5, with generics as the primary new feature. The nice thing about Pascal? It’s fixed. No one was adding new features, because there was no need. It was a teaching language. Sure, it lacked separate compilation, and certainly wasn’t OO, but no one was going to fix the language in major ways.

Even now, many a Java educator wants to teach a controlled version of Java, that limits what students need to know, and they would like to fix this version of Java so that students, and more importantly, teachers, don’t have to keep up with the latest changes in Java.

And that’s what this blog entry is finally all about. Why are teachers reluctant to teach real languages? Because real languages evolve, and many teachers aren’t thrilled that their knowledge of a programming language is going to go obsolete if they do nothing more. Which other disciplines does this affect? Math? Nope. English? Only very slowly. Many fields, once you learn it, that’s it. There’s no strong need to learn more, though you certainly can, and students benefit from it.

Programming? There are universities that won’t switch over to Java because the professors don’t want to learn the language. They spent time learning C++, and the languages don’t seem that different, so why bother?

A teaching language is clean; it avoids lots of details you may not care about to explain, that real languages have to deal with. When you have to learn minutae of the languages that seem to have no other purpose other than to confound you, you wonder why it should be taught in the first place.

But unfortunately, as nice as that is for teaching purposes, it avoids reality, and the reality is that real languages are not always so clean. Most teachers are content to say “They have to start somewhere, and I’d rather start them on a nice clean language”. Which means to say they don’t ever want to teach a language that’s grungy. We must do it for the children. The children!

But of course, the reasons are partly to insulate the teacher, who doesn’t want to teach these details, and partly because programming is simply hard. A programming teacher, at least, those who aren’t bitterly cynical, believes everyone can program. As they teach, they see some students struggle. Some struggly mightily. They begin to say “It’s not important to learn syntax! Look it up! The conditional operator is a nasty feature. Let’s not cover it!”.

Eventually, this teaches all sorts of bad habits to programmers. The lesson programming apprentices should learn is that experts learn the nooks and crannies of the language, the parts that may seem obscure. For example, continuations are a big feature of Scheme. To avoid teaching it is to avoid teaching a critical part of Scheme (well, maybe not “critical”). Great programmers learn the obscure features of a language, even it’s not widely familiar.
Having said that, I’ve been coding in C++ again, with STL, and find that I must think about const a lot, and how to use iterators, and all sorts of mess that I don’t have to deal with in Java, because I understand Java’s classes much better, and it makes a lot more sense to me. That may simply be familiarity, but the time I waste trying to think about const makes me that much less productive, despite my acknowledgement that const is an important issue which all C++ programmers need to know. (Again, my colleague found const correctness a pain to deal with and wanted to abolish it).

There are even more radical ideas (radical to me, anyway). There are universities that want to ditch strongly typed languages in favor of weakly typed languages like Python and Ruby. These languages often have powerful string methods and regular expression support. Powerful code can be written in a few lines.

I do see some advantage in this. I think I’d write a lot more useful tiny programs if I were more well-versed in Python or Ruby. I find writing some programs in Java or C++ really painful that would only take a few lines in these languages. But honestly, they should have some strongly typed subset of these languages so that there can be some error checking at compile time. Please. (Groovy, a scripting language, built on top of Java, and compiles to Java classes, seems like something that might fit the bill).

So I can see both sides of the issue.  On the one hand, all the plethora of features makes it difficult to learn a real-world language.  It’s hard on the teacher.  It’s hard on the student.  On the other hand, it’s also polite fiction.  If students are expected to learn real-world programming, they need to worry about all of this perceived nastiness.  Teachers want students to learn less (i.e., stick to the basics), while the real-world wants them to learn more.

It may be, in the distant future, the teachers will be right, but I doubt it.  Here’s one example. Internationalization.  Java had to switch to Unicode to deal with international character sets.  How many teachers really want to explain, to American students versed in English, anything about internationalization?  None, I’d imagine.  It’s hard enough to teach programming (loops, functions, inheritance) without having to even mention internationalization.  Yet, it’s a topic of concern for many developers.

Software development is getting more mature, but in the process, it’s making the teaching of computer science more challenging.  I can’t say I honestly know the answer about what language to teach first, only to say that the reasons teachers push students in that direction may be at odds with the real world.

Tim Meyer Rants

Tim Meyer had a rant today.  Who is Tim Meyer might you ask?  I have no idea.  He appears to be a professor or something at a place called Buena Vista University, which despite its sunny name, appears to be in Iowa (not to say Iowa doesn’t have sun).

In it, he complains about the lack of enthusiasm from his students, as if they don’t care about their own education.  He ponders why this is the case.  He figures that students simply don’t like school.  They go through the motions, and then they graduate.  Simple.

Let’s see what he says in his rant:

At this point in the class, I had spent the previous 38 minutes doing introductions, and explaining every last detail of the syllabus. At this point, approximately 50% of the class started to pack up their material in preparation for an early departure.

Now, let’s sit from the student’s vantage point and think about what just happened.  Is what happened any different from any other opening day lecture?  Going over the syllabus.  Encouraging folks to study.  I mean he says he goes through every last detail of the syllabus.

What exactly are the students learning at this point?  Rules that they won’t pay attention to until it actually matters.  Are they learning anything about economics?

That first day went to waste.   At times, I think you should hand out the syllabus, and not even discuss it.  Get to that first topic.  Tell students why this class is so important to them.

Go up to the students.  Interact.  Pose a challenging problem for them to think about.  Not everyone who takes a class wants to take a class.  You have to think of yourself like a movie that’s coming out.  How do you get the attention of people who don’t want to be parted with a ten dollar admission ticket (for my foreign readers: that’s a chunk of change, i.e., that’s a lot of money)?

I know.  You’ll say “I’m an educator, not an entertainer.  I shouldn’t have to work this hard to get the students to learn.”  But you do.  Just like every movie works hard to get you to show up.  If you simply expect your material to be compelling just because, it’s not good enough.  You’re a salesperson, and they’ve got to be interested in what you’re selling.

For example, this is how I open up a lecture for a computer architecture class.

You’ve spent the last few semesters learning how to program in a high level language called Java.   And many of you who choose to become software developers, which is quite a lot of you, though I’m sure a few of you will abandon this to find other areas of work you find more interesting, like real estate or teaching Spanish.  I’m not kidding.  After the hundreds of hours you’ve spend learning how to program, and the thousands more you’ll continue to spend trying to make yourself better and better as programmers, some of you will call it quits.  This is not what you want to do the rest of your life.

But for the rest of you, you need to get beyond the fantasy land that is Java.  Yes, Java is a perfectly good language, good enough that Microsoft basically copied it and tried to improve on it with C#.  These languages hide a lot from you.  And that’s normally a good thing.  But if you’re going to be good programmers, no great programmers, you’ve got to know something about computer architecture.  That’s right.  Hardware.

Oh, I know what you’re thinking.  Hardware is for electrical engineers.  I’m never going to have to deal with any of that.  But you’re wrong.  One day someone will want you to write programs that run faster, and knowing something about caches may save you.  When you see stack overflow, you have some idea what that means.

But we’re going to do better than that in this course.  How many of you think about what happens when you hit that compile button in your IDE?  How many of you wonder what that high powered CPU is doing?

It’s running machine code.  When all gets said and done, a CPU runs machine code.  1’s and 0’s.  Lots of them.  Real fast.

And while you think this hunk of silicon is beyond comprehension, and only those who pray to the altar of silicon gods can ever fathom the mysteries of how a computer works, you’re wrong.

Absolutely wrong.

For in this class, we’re going to build a computer.  We’re going to build it from logic gates, a clock, and wires.  And this computer is going to process machine code.

But this isn’t the kind of computer construction many of you may think of.  How many of you have built a computer?  Raise your hands.  What you did was tinker toys.  You bought a motherboard?  And a fan, and a power supply?  And then hooked it together.  Put in some memory, installed Windows or Linux?

Those computers, to be fair, are far more complex than the kind of computer we’ll build.  And the computer we’ll build is a paper computer, meaning I’m not going to have real hardware, but you will imagine that it could be built, if we had the right materials.  And when we finally get it done, you’ll figure out that that magic that makes the computer run your programs is not magic after all, and in this understanding you will gain knowledge and wisdom about programs  and how they really work that you never would have had you not taken this course.

How many of you are ready to take the first step of this journey?  How many of you are ready to cast the Java yoke off your shoulders and roam free into the world of hardware, the world of computers?

Let’s begin.

Now, how many students do you think are paying attention to that, as opposed to covering the minutae of the syllabus?

I have other ideas on how you can get students to try to form study groups and such, but it’s more than simply lip-service.

As teachers, we have something to sell, and that’s education.  When you learn that you are in the business of selling, then you’ll find that students may be willing to buy.

Experience Counts

Suppose you’re teaching a course that you know little about.  I wanted to say “nothing”, but most people with a decent background know a little about most topics, even if it’s not sufficient to do anything about.

However, even with knowledge of the subject area, there’s going to be times when you’re covering something advanced or you have bright students, and you’re not going to be able to answer the questions they ask, because you’ve never given it that much thought either.  As long as you’re willing to look silly initially, and then try hard to find the answer, you’ll end up doing a much better job later on.

And that can be tough.  Most people don’t have that much humility.  I recall listening to someone say that C++ was compiled to C before being compiled down to machine code.  While that was true once upon a time (you’d write your C++ compiler in C, then cross compile the source to C, and then compile both with a C compiler), I don’t think it’s true now (and hasn’t been true for a decade).   Even facts you thought you knew about Java based on knowledge of compilers may no longer be true (vectors, for example, can now be optimized not to do locking, if the compiler can detect that locks aren’t needed, thus removing the overhead of locks).

If you have time, and know of a colleague that’s taught the subject well, sit in their class.  Find out what they do.  You can take ideas you like, and avoid pedagogical practices you don’t.  I find that sitting in a class on a subject I know well is great, because I can focus on the teaching, and see what examples are being picked and why (it tended to make the person lecturing nervous, because they would wonder what my motivation for being there was).

Teaching often teaches you why the subject matters, and if you can’t figure it out, you should be looking for reasons.  Your lack of enthusiasm can translate to lack of enthusiasm for the students, and while some of the best teachers (I say this hesitantingly) may not be enthusiastic, most are.

I’ve made the tacit assumption that you’re an expert on the topic you teach, but really, there’s always much more to learn.  When I taught C++, I spent time learning about STL.  I wasn’t an expert by the end, but STL was hardly mentioned by anyone else.  For a subject as fluid and dynamic as computer science, you should always be finding the latest trends, the newest topics, and trying to figure it out.  The more you visit and revisit a topic, the better you get at the topic, attacking it from different angles.  I can’t tell you how many times I’ve thought about two’s complement, and still there’s stuff for me to learn there.

Teaching is a lifelong endeavor.  You get better over time, even if the first few times may be embarassingly bad.  You just have to care enough to try.

More Than Just Programming

I’ve just received my first comment by a fellow from Portugal, so one other person out there is reading this.  Ah, the amazing power of search when it comes to blog.

I wanted to quickly blog on something that’s been on my mind, which is that programming is more than just programming.

Let me list out some distinct skills that “good” programmers have:

• Basic control flow/syntax of a language (loops, functions, classes, etc).
• OO skills (inheritance, templates, design patterns)
• Algorithmic skills (quicksort, binary search, depth first search)
• Tasteful design (write “general” code)
• Testing
• Debugging
• Learning new tools (debuggers, profilers)
• Learning IDEs

Several of these topics are not regularly covered in programming courses.  In particular, little time is spent discussing the debugger and about the debugging process.  More generally, not much time is spent on learning new tools.

Why?

As fast as programming languages change, they are relatively steady.  If you learned Java 1.1 from 1998 or so, then you’re still more or less good for programming now.  Maybe you have to pick up generics, but you don’t have to, if you don’t want.

However, Eclipse and others are pumping out updates on IDEs every year or so. It can be extremely difficult to write an up-to-date book on IDEs.  Plus, you never know when one of those IDEs will be shut down.  I knew someone who wrote a book on Visual Age, which was IBM’s Java IDE.  He made a little money on it, but they eventually shut the project down, and so no more money on that book.

If you write a programming book with an IDE in mind, you cut down your audience too.  If you code in emacs using gcc, then that book on Visual Studio may not be that useful to you.

And with IDEs as complex as they are, it can require its own book (and often does) to cover even the basics, which detracts from the main effort of teaching a programming language!

But what I want to talk about is the desire of students to learn tools on their own.  Many students who come to programming like to work in a shell.  I don’t mean like Korn shell or Bourne shell.  I mean, they like to work in something familiar.  Here’s a test to show this kind of thinking.  You tell a student, who’s been editing in emacs, that there’s a cool IDE called Eclipse, and it has a ton of cool features.

What’s the reaction?  Does the student say “That is so cool.  I’ll download it and try it later today” or is it “That’s fine.  I’m happy with what I’m using now.  I don’t have time to learn something new”.  It’s this second attitude (and I’m somewhat in that camp myself) that is bad for programmers working in the real world.  As uncomfortable or unnatural as this is, they have to learn to play with new stuff all the time, even if it initially wastes a lot of time.

You know those Linux fans?  They tell you to abandon PCs or Macs in favor of Linux?  But then they spend 2-3 days trying to install Linux in exactly the configuration they want.  That’s the kind of attitude programmers need, sadly.

I say sadly because it is a waste of time.  There are so many tools out in the real world that haven’t been updated in a long time, mostly because the functionality is so minimal.  Real world software and consumer electronics has a gazillion features, and many are a bit too complex to use, so there is motivation to tinker with the features to make it easier to use, while adding even more features.

And yet this skill of learning new technology is not taught.  It’s such a nebulous skill, after all.  You tell a class, download this new profiler, and tell me what results you get.  How many say “but you need to teach this to us first”, i.e., predigest the act, make sure any errors that occur you deal with, so we don’t have to.

Many non-programmers are techno-phobes.  They hate this uncertainty.  They don’t want to tinker until it works.  The first sign of something wrong, and they want to panic, and quit.  Or they ask a guru to do the work for them because they don’t want to be the one spending two days figuring stuff out.

How do you teach this desire to tinker with new technology?  Other than programming itself, it’s one of the most valuable skill a programmer can develop (or anyone interested in technology).

Master Coders (an opinion piece)

Computer science departments have this dilemma.  It’s easy to cheat in computer science.  Copying code is as easy as sending email, or transmitting a file via IM.  For this reason, computer science departments have often been draconian in the way they police cheating.  CS departments get a bad rap.  I recall, at the University of Maryland, that the newspaper (or some such) claimed that cheating occurred more often in CS than any other department.

So it turns out cheating is easy, but catching cheaters is somewhat easy too.  You can do analysis of programs to compare their similarity.  Other departments had to catch cheaters the old fashioned way.  They had to care.

That’s too bad, really.  Just as would-be writers can look at good writing to learn how to write, good coders should look at good coders to learn how to code.

This is where I think technology can help.  I was sitting at a session of Ruby on Rails conducted by none other than David Heinemeier-Hansson (DHH for short), inventor of Rails (who’s getting a run for his money from the Django guys).  Now, I had sat through a session by Dave Thomas and thought I knew the basics of Ruby on Rails.  I was told later on by Jared Richardson (hi Jared!) that this was the “Dave Thomas” effect.  He makes you think you understand what he’s saying, when he’s actually glossed over some details.

DHH convinced me that I didn’t know what Rails was about.  I wish I had because watching him code live with half an understanding of what he was doing might have been enlightening.  The best coders sometimes code in a very odd way, and it would be good to see good coders code.

I’m not a great coder, by any stretch, but my experience coding in Java makes me want to code up interfaces a lot.  I also try to use library functions when I can (STL has been confounding me though).

The point is that coding (at least, on the fly) has many decision-making steps.  I think about which classes I want to write, and tweak methods as my quick decisions appear to be mistakes.  Some people might plan their code out much better, thinking of how they want interaction to occur.

I sat with someone who wanted input to be handled from a stream so that the code would remain the same whether it was from a file or from a URL.  He believed in generalizing the implementation when possible.  This kind of philosophy goes beyond simply getting the code to work.

Suppose you’re into refactoring.  How would that affect the way you code?  What issues should one consider when solving a problem?

Pianists often learn by sitting in master classes.  They are asked to play a song that is familiar to them and the teacher.  The teacher gives advice along the way.

Similarly, I think master coding sessions might be useful.  This is something I wouldn’t try with beginning coders, as they are struggling just to learn how to program, but once they have, say, two semesters of coding behind them, they can start to think about these issues.

Indeed, computer science departments should really have a course on programming that is aimed at the senior level.  Most departments think of programming as learning the features of a language, and should be aimed at intro-level courses.  By the time students reach their senior year, courses change to applications or theory.  Programming is seen as a tool, and is no longer studied in and of itself.

The closest course that covers this kind of programming is a course in software engineering, but a good SE course should cover stuff like requirements gathering, use-cases, design docs, testing, etc.   Sometimes a good project course will hit those issues (say, a good games course).

Ultimately, good programmers develop a kind of taste.  They know how they like to structure code that goes beyond the basics of getting stuff to work.  They think about efficiency.  They think about abstraction.  They think about clarity.  Sometimes they think about getting stuff to work, realizing they are sacrificing generality or clarity for speed.

But students of programming seem to learn these skills almost despite a system that tells them not to look at other people’s code, or that structures their code so highly that they don’t think about it.

So, my solution?  Get a few easy problems that can be coded in Java or C++ or what have you, and get a few master coders to code it up, and compare it to a relative novice, and see discuss the results.

The Course In a Nutshell

It’s your first day of class and you’re getting the basic logistics out of the way.  The syllabus. Who’s registered in the class.  And so forth.

At some point, though, you should be selling the course.  The students have signed up for the course.  It may be a required course.  It may be an elective.  Regardless of why they have signed up for the course, you should explain why this is the most important class they’ll ever take.

In reality, of course, it may not be the most important course they’ll ever take, but you have to find some reason that you think they should take it.

Let’s illustrate.  For a first programming course, you want to explain what programming is and why you think programming is something worth learning.  It helps if you like to program.  Write a simple game.  Maybe “Connect Four” using Java Swing.  Show them that this is the kind of thing a knowledge of programming allows them to do.  It is a kind of creative tool that allows you to do all sorts of things from playing games to downloading stuff to manipulating files.  The possibilities are limitless.

It helps to point out the pitfalls.  Programming is not easy.  It’s easy to make errors and hard to find them.  Unlike people, programming languages are very strict.  You must understand how a language works.

But relate that to some other experience.  If you were to learn how to ride a bike as an adult, you might fall down so often that you give up.  Why go through the pain and suffering?  However, with enough practice and skill, riding bikes is fun.  It’s a way to stay healthy, a way to use something besides a car to get around, a way to meet people.  Anything worth learning is going to take work, and lots of it.

Suppose you’re teaching a course in computer architecture.  At this point, a student has typically taken a few programming courses, maybe a discrete math course.  This is the first course that isn’t either, and they may find it strange. “I’m not an electrical engineer!  I don’t care about hardware!”.  You have to convince them that hardware is important.  A solid knowledge of hardware can help them do things more efficiently.

But I try to take a different approach.  I try to say that the computer is not magic.  With a few basic tools, they can learn how a computer works.  It may not be the most advanced computer in the world, but the basics of every computer do what you’re about to teach them.  A computer can be boiled down to wires, gates, flip flops and a clock.   From that, if you attach things correctly, you can create a basic assembly language that can run programs.

Just that alone is worth taking computer architecture.  Since I’ve taught the course many times, I try to relate their programming to the course.  I cover pointer arithmetic in the course.  I translate basic C code into assembly.  I even have them write an interpreter for assembly language.  It lets them see how assembly language can be executed.

For a networking course, you might give a small history lesson.  Imagine it’s 1984.  Big Brother is out there.  OK, he’s not.  But you have an IBM PC or an Apple Mac.  You want to find some information about, say, combining Coke and Mentos.  Ah, but there’s no Web.  There’s no Google.  In fact, you’re barely connected to the outside world.

If you want software, you have to go out to the store and buy it.  Or trade it physically with your friends.  Later on, there are some places you can dial into with a “modem” to get stuff from well known sites.  But there’s not much of a network you can tap into.

And now, people quiver if they don’t have their Internet access.  It becomes their drug of choice.  How does the Internet work?  How does information travel?  This is cool stuff.

The point is, with each course, you’re trying to sell the importance of the course, how it will affect them in the future.  Obviously, practical courses, ones that can be used immediately in the real world are easier to motivate than more abstruse topics.  But if you love functional programming languages or Smalltalk or Erlang then try to convey why you think it’s important to learn those languages.  If you feel lambda calculus is the bomb diggity, explain why you think they should learn it.

That may force you to figure out why, but you too should think about the reasons.

From that point onward, you may try to develop a theme for your course–a bigger picture the student can think of, the forest, as you describe the trees.

Understand the big picture.  Convey the big picture.  Remind them of the big picture.

Teaching a Small Class

I want to teach a small class.  I mean, really small.  Ten students, tops.

I’ve taught classes where there were 70 or more students in the class.  And I tell you, while that is fun in a performer sort of way, it’s also one-size-fits-all.  A large class means that everyone gets the same assignment, gets the same treatment.

Now, you may say, but isn’t that only fair?  How else would you teach a class?

Suppose your class is really small.  Then, you can begin to think about running it like an individual tutoring session.  You can think of having discussions like they do in English classes.  You can tailor each person’s education to their own speed.

I know, I know.  When on earth do I have time to do that?  I have a life too, you complain.  But imagine, if you could, at least, having each student pace themselves in a class.  You have a list of tasks that students must master, and your lectures will hit a certain pace, but students can go slower or faster.  They also have concrete ways to measure how well they are learning the material.

I’d like to do a videoblog for advanced students so they can go ahead and learn other stuff.  I’d like to do videoblogs for students who need additional help in some task they are working on.

And if I do a good task tracking what they do, then I can see how they are progressing, and make sure they learn a few things well, even if they can’t learn everything that I hope for them to learn.

In many ways, I see this much as a project manager might see things.  In particular, such a manager tracks the progress of several developers.  A good manager realizes that not every developer works at the same pace.  Some work far faster than others.  Thus, they must pace out the work based on the working speed of the developers.

Similarly, with a small class, you can track the individuals within your class, and create definable ways for them to demonstrate their knowledge.

This raises a question.  What about tests?  Well, in such an approach, you might consider something like a certification exam, much like those for Java or some such.  Think of this as a multi-part exam.  Some students might be taking part A, others part B, and still others part C.  That makes things tough to grade, I admit, but with a small class, it might be more effective.

Realize that in a small class that you might be able to achieve things in a different way from a larger class.

I understand there may be drawbacks.  For example, will students resent the fact they are behind?  How do students work with one another if some are way ahead of others?  How do you manage all this additional work?

I don’t have all the answers as I’ve never taught such a small class, but I think it’s worth thinking about compared to a large class.

The Passive Student

Many students head into college without a good knowledge of how to survive college.  Sometimes the reason is simple.  Their parents didn’t get far with their education or never knew how to survive either.  Children of academically successful parents (should) have heard the lessons of being a good student.

What does it mean to be a good student?  Two things.  Discipline and actively thinking.  Discipline means that you spend time to do the required work with sufficient time.  You say no to parties.  You say no to a night out.  You say no when there’s work to be done.  You read the book even if it bores you to tears.  You study for a test even if you feel there’s no benefit in your long term education.

Ideally, classes should give you a reason for why you’re in the class, and ideally you should buy into it, but in case it doesn’t, there’s always being disciplined.  This is why I think musicians sometimes have great success in computer science even if you think music and computer science is very different.  Discipline.

But, beyond that, there are some basic survival skills in the class.  Students come in and listen.  And yet, they don’t have questions to ask.  They don’t know how to ask questions.

Here’s the problem posed to you.  How can you get students to ask questions?

The first thing is to make students aware that they aren’t asking questions.  That, by itself, isn’t enough.  Just because you say “you must ask questions” doesn’t mean that they’ll magically know how to ask questions.

Try the following instead.  Have the students summarize what you said in the last five to ten minutes of the lecture.  If they get stuck, then you can at least get some idea why they are stuck.

Have students learn how to summarize because summarizing is a form of learning.  It means the student knows what’s the most important point you’re making.

Another approach is to have them imagine that they have to prepare the same lecture you’re giving for tomorrow.  If they had to present it to someone else, then they have to be far clearer on what’s going on than if they are learning it for themselves.  It’s amazing how much more people do when they are responsible for others than for themselves.

I imagine saying the following to a class “Prof. So-and-so wants me to cover his class.  He’s going to cover what I’m going to cover.  But I don’t want to cover his class.  I want you guys to do it.  So if you do a bad job, I’ll kick your posterior!  So if you don’t know what’s going on, you better ask me while you still have the chance”.

I dunno.  Maybe not.

Point is, the more active the student is in their own learning, instead of relying on you to “force them” to learn, the better off they are, the more they will learn.

Rethinking Lectures

I want you to think about how classes are taught.  Not computer science classes in particular, but any college or high school class.

Classes are taught in a classroom.  There are chairs, many with tiny desks, the better to cram into a room, so that space is conserved.  Students typically carry a backpack with a notebook, possibly books, and something to write with (we’ll pretend this is before 2000 and students haven’t brought notebook computers with them).

The teachers lecture in front of a class, in front of a blackboard with chalk in hand, or maybe even less.  They simply talk.  Students take notes.

Here’s my question.  How much has this style of lecturing changed?

I’ll start rattling off the changes I’ve noticed.

Even twenty years ago, there was some crude ability to project a computer monitor onto a large screen so students could see it.  Barring this, the overhead projector has been around a long time as well.  Teachers can make transparencies with complex diagrams ahead of time and display them.

Let’s think about this.  Maybe you’re showing a complex circuit.  Drawing it on the board would be really tedious.  A diagram photocopied from a book and made into a transparency would save lots of time.

But then, how do students copy this information down?  If it was laborious for you to copy it by hand, how do you expect students to do the same task?  Two solutions.  Make a copy for each student.  Have students refer to their book, assuming you got it from a book.  A third solution is even more convenient now that we have the Web.  Post the handout.  Still, in a class setting, handing out a diagram so students can take it home seems reasonable.

It’s hard to say the whiteboard is much of an advance.  It simply shifts the medium from chalk to markers.  Some people allergic to chalkdust might find this a relief, but there are those who don’t like fumes from markers.  In any case, the shift to whiteboards, to me, is much like going from pencils to pens or pencils to mechanical pencils.  They don’t give you much of a pedogogical advantage.

Blackboards and whiteboards have downsides and upsides.  The downside is that it’s a temporary medium.  You have to constantly erase what you write.  Wouldn’t it be nice to save all that writing so it could be called up later?

It does have an upside, however.  Because you are writing on the board and because you have a limited speed, you can only write and lecture so quickly.  This keeps your pace slow enough for students to keep up.  Of course, some teachers find writing on the board very tedious, and avoid writing as much as possible.  They figure they can simply speak and students will simply write notes.

If you’re one of those folks, I want you to think about this.

If you’re too lazy to write on the board, what makes you think the students should be so energetic as to write whatever you say?

I know what you’re thinking.  You’re the teacher.  They’re the student.  You can be lazy, since you know the stuff.  They can’t.

Writing on the board means you have to decide what’s important enough to write down, and most people write down far less than they say.  Thus, what they write down should be important.

But, let’s back up.  Let’s think about this process.  You write stuff on the board.  Students write.  That’s between 10-100 students copying down what’s on the board.  We have 100 scribes copying stuff.

Isn’t this the most inefficient way to convey information ever?  In the past, when photocopying was expensive, forcing students to buy paper and copy what was on the board was a reasonable way to convey information.

These days, this isn’t the case.

Now, there is one reason I can think of to make students copy stuff down.  Some students learn much better when there’s a second way to ingest this information.  In addition to hearing the lecture, writing it down can help reinforce the ideas.  Personally, it didn’t work that well for me, as I often thought about my penmanship rather than pay attention to what was being written.  They could have written in French, and I would have dutifully copied it.

There is a second reason.  Writing is an active process.  If students are planning to take notes, they must be writing.  Writing therefore prevents students from falling asleep.  If you, say, promise to make notes available to students, then they can, somewhat justifiably, fall asleep in your class.

OK, so let’s review the technology so far.  Overheard projectors allow you to present complex diagrams and prepare for lecture materials ahead of time.   Whiteboards don’t provide that additional value over blackboards.  Both provide a temporary scratchpad.

The next big revolution is Powerpoint, or some equivalent, and the ability to display computer content on a large screen.  Powerpoint has advantages for the teacher over transparencies.  Transparencies are physical.  This means you must store them somewhere and hope not to lose them.  They are also permanent, which means it’s hard to edit them (or they are not, and you have to be careful about erasing the contents).

Powerpoints store information in bits on files, which means they can be copied around, posted on webpages, on so forth.  You can also edit them on the fly, if you have your laptop with you.

The advantages for the teacher are plenty.   Unlike transparencies, Powerpoint is not physical.  Thus, provided you have a projector for your computer, you can edit on the fly, if need be.  Plus, if you have lousy handwriting, Powerpoint can make it legible.

What is challenging about Powerpoint are things like diagrams, equations, tables, etc.  They can be planned ahead of time, but it takes work.

Many computer science teachers use Powerpoint because they use them in academic conferences.  It’s a tool they are familiar with, and so they use it.  However, not every academic goes to conferences, and some don’t want to learn how to use Powerpoint.  They complain that it’s hard to write equations and such (and are probably correct about that).

Powerpoint has one disadvantage over blackboards/whiteboards.  They require (for the most part) planning in advance.  There is many a teacher that would rather not prepare for a lecture.  They know the material off the top of their head and can lecture without preparation. And, in other ways, they are completely disorganized.  Being able to give a lecture on the fly means you can be much lazier when it comes to presenting.  Powerpoints don’t work because there is labor to make it work.

But for those who like to prepare ahead of time, it works well.

Is it better for students?

Let’s think about it from the student’s perspective.  I see Powerpoint slides.  Since they are slides, I may have to dim the lights.  Since I have to dim the lights, some students may begin to nod off.  The point?  The technology is almost there, but not quite.  You need to be able to present Powerpoint in full brightness, without having to dim the lights.

Lights aside, what advantages or disadvantages are there?

First, Powerpoint slides encourage bullet points, and somewhat discourage diagrams and equations.  So those two may disappear from the presentation.  That might be bad.  Powerpoint also encourages speeding through a presentation.  Forty slides in forty minutes may be typical.

But the worst danger is the availablity of someone else’s slides. You don’t have to prepare your own lectures anymore.  Just steal (er, pay homage) from someone else.  After all, you use a book that someone else wrote.  Why not use someone else’s notes too?

Simple.  Powerpoint slides are simple shorthand for a lecture.  Books are self-contained.  They are much more likely to contain all the infomration you want and more.  Slides are likely to contain far less than the lecture could have conveyed.  Worse still, you don’t get those additional thoughts the presenter may have had.

25 Powerpoint slides may translate to 25 full pages in a text book, which would really be 100+ slides in a lecture, too many to cover.

Beyond Powerpoint, many computer science teachers are now starting to use their desktops to display content to the students.  This allows you to present an IDE and edit a program while the student watches.

I have to say this is much like watching Bob Ross paint.  You think you’re learning something by watching him paint, but you’re not.  Not enough, anyway, to really make a difference.  You have to paint, and then you can begin to appreciate what he does.

IDEs aren’t even as pleasant as watching Bob Ross paint.  There are many buttons and sequences to press that perform functions that baffle students.  And worse than Powerpoint?  No words to write down?  They have to somehow take notes on something they hear and see, by doing what?  Trying to draw the IDE?  Trying to describe what’s going on?  They say a picture is worth a thousand words.  Do students have time to write those thousand words down?

There are some solutions to this, but like Powerpoints, they take time on your part to master.  The one solution I’m aware of is Camtasia, which is a software product that allows you to record yourself and a screenshot, and annotate the live screenshots (and pause if need be) to present information.

Another idea that ought to appeal to those who don’t prepare much is the Tablet PC.

This offers the advantage of blackboards (i.e., handwriting, being able to whip up lectures at the last moment) and the advantage of computers (being able to pull up complex diagrams, displaying an IDE, etc).  There is still a learning curve for the teacher, but at least it doesn’t require much prep time if you don’t want to prep for a lecture.  And it has the advantage that you can save the contents of the lecture instead of erasing it.

Ultimately, I think educational presentation software needs the ability to do that.  Be able to present information on the fly.  Be able to record the content.  Be able to move that content to a webpage or some other storage.

In a nutshell, presentation software needs to have the advantages of the blackboard, without its disadvantages.

Technology has been used to some limited success, though it’s far from ubiquitous.  Ironically, other disciplines are sometimes far more likely to use technology than computer science professors.  Why?  Because many professors, especially those from a certain generation or older, simply are afraid of technology.  They hate to learn the stuff.  They hate the fact that the technology keeps changing.

Blackboards have stayed the same for a hundred years.  Can the same be said about presentation technology?  No.

I’ve presented a lot of ways we lecture to students:

• blackboards/whiteboards
• overhead transparencies
• Powerpoint slides
• display IDEs or desktop on a screen
• handouts

However, there’s something in common with all these things.  They are presenting to the student.

And that’s what I think is wrong with teaching these days.

We simply haven’t made much progress.  There has been some progress made in presenting material, but they have failed for two reasons.  First, they don’t allow people to easily lecture at the last minute.  Second, the technology doesn’t stay stable enough that what you learn today can be applied to presenting material in ten years, in twenty years.  Of course, we expect advancement, and perhaps this is the price we pay for technology.  Any knowledge you have is obsolete in three years.

And it’s not the useful kind of knowledge either.  It’s the kind of stupid knowledge that you have to know how to make tables or bullet points or write equations and know that some things you could do on a blackboard, you can’t do (easily) in Powerpoint.

But back to my point.  This technology is aimed at presenting.  While I think presentation software still has a long way to go to be easy to use, powerful, and spontaneous, it still presupposes that what we do as teachers is to present.

Let me give you a different scenario.  Suppose you’re tutoring one person.  How would you behave differently?

Now, I’ve seen people present to students in office hours.  Some go into a long lecture as if they were presenting to a class of twenty except the student can interrupt far more often than in a real class.  This had advantages.  The class can be tuned to that one individual.

But, there are still more advantages.

Learning should be a feedback loop.  As I’ve said before, I see teaching and learning as going hand in hand, and that good teaching means verifying whether students are learning.

If you had a single student, you could show them how to write a “Hello, World” program.  But then, you could take away the program you wrote, and have them go through the steps themselves.  In other words, in a one-on-one setting, you don’t simply lecture, you get the student to answer questions that demonstrate they know what’s going on.

And that’s what’s missing.  It’s that simple.

You’re lecturing in the belief that students are learning.  But how do you know they’re learning?  You don’t.  I mean, you do, based on your past experience and seeing that lecturing, while not efficient, is modestly effective.  It works well enough.

And how do you know it works?  Because finally you ask them to turn in assignments and take exams, and you can see the results of what you do in class (and what they do out of class).

If push comes to shove, you’d have to admit that it’s generally too difficult to learn everything while sitting in a class.  You must go back to the dorm room or library or a room in your folks place or someplace and spend sometime thinking, figuring stuff out, piecing it together.  Some do this with a book.  Some ponder in their heads.  Some talk to their friends.  Others to their TAs or teachers.

Can lecturing become something more interactive?  Something where you can verify what students are doing?

One reason interaction is helpful is that it forces you to confront your assumptions.  Even as you think you know what students ought to know, there’s nothing like interacting with individuals to find out what they know, or what they don’t know.

As I’ve mentioned before, were I to go back to teaching, I’d sit and think about how to make the class more interactive, because I feel students learn by doing.

Ideally, I’d want students to do some work outside of class so that in class I can do more interactive things.  But how can I do that?  One way might be to make assignments that involve reading something for each class that they need to respond too.

The other thing is to produce, for the ADD in all of us, smaller bite-size things to learn.

The third is to take advantage of webpages more, so that students can keep up with course content much like they may keep up with their friends MySpace accounts.

I’m not saying we should throw away lectures, because they have their place too.  For sheer efficiency in communicating a lot of information, lectures are good.  However, they put students in a passive position.

I’m going to write two more entries on this topic.  One on teaching smaller classes, and one on the passive students.

The First Day

I’ve thougt of something silly that you should think about for the first day.  It’s almost so silly that many people just don’t bother, but it might do the students in your class a service.

Print up a roster of registered students in your class.  That way, you can read it out to make sure people who think they are signed up are indeed signed up.  Also, you may want to figure out whether you should oversubscribe students, assuming there is a limit to how many students can take your class.

On the first day, typically you want to hand out a syllabus, check to see whose registered, and describe what the class is going to be like.  Why should students take this course (other than it’s required)?  What are your thoughts on the course?

Personally, I like the idea of trying to teach stuff right away, even assign a first project.  It gets the class off to a start just when students are eager to do something anyway.  Enthusiasm is often quite high at the start of a class, so give folks something to do.