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.

Writing a Project for an Intro Class

A programming course needs programming projects.  Some people don’t quite give projects.  They think in the old-fashioned style.  You give problem sets to students, so tiny programming projects are considered problems to be solved.

For an introductory course, you want to keep the projects fairly short, say, no more than five hundred lines for a final project, and perhaps no more than 50-100 lines for the first project.

The biggest question to answer is how much should the students write and how much should you write.   Most people favor having the students code everything because that’s less work for you (if you write code, you have to debug it first).  That’s fine.  I have no opposition to this idea.

There is a trend that’s been occuring over the last ten years or so, and that’s the use of libraries for introductory courses.  Even in the 80s, students had to use one library–the I/O library–so they could print and read input.  Now there are libraries for everything.   Yet, some teachers are leary of teaching students to use these libraries.  They shouldn’t be.  We don’t want to teach students to write their own code all the time.  They should use libraries when they can, even if it’s awkward.

For example, I use the STL.  I don’t particularly like the way the libraries work, being used to Java libraries.  Nevertheless, it doesn’t make sense for me to write my own because I’m using something that’s less generic, less powerful, and worse, I have to debug it.  Someone has already debugged STL.

The question is what you should teach in a programming class.  When I was teaching intro courses, each project was based on a control-flow structure.  Initially, there was just straight line code.  Then conditional statements.  Then, loops.  Then, functions.  Then, pointers.  Then, “C” structures.

This is one approach, and it has some merit.  It focuses on the tools available within a language.

However, you also have to keep in mind that writing programs is also problem solving, so you may want to think about the kinds of problem solving skills people need.  Sorting, searching, and so forth.  For an intro course, even those skills are too challenging.  You may want to do linear search, simple swap, iterating through an array, selecting items through an array, and so forth.

But think about problems.  Some people assign a “connect four” game where students must develop the logic to find four in a row.  Or they might have five cards and have to detect a 3-of-a-kind.

Keep both things in mind.  Programming is both about learning features of a language (which is specific to the language) and about problem solving skills via programming (which is a generic programming skill).

Thinking About OOP

Suppose you’re teaching Java.  I pick Java because it is widely taught at universities and because I’m more familiar with Java than other languages, though you could apply what I say to C++ too.

You begin to teach the features of Java.  This is what an interface is.  This is how you write one.  This is how you implement it.  This is how you declare a class.  This is how you declare methods.  This is how you make stuff private.

But, ask yourself, why did Java do things this way?  This is a much harder question to ask, and requires deep understanding on your part.

In particular, I want you to answer the following: what’s the difference between a class and an object?

That’s a key question to answer, not only for yourself, but to the students too.  I see the class as a cookie cutter.  It’s a template (not of the C++ variety) and objects are cookies.  However, classes and the objects created from the classes are tightly coupled in Java.

To understand this, it helps to know a different language like Ruby where data members and methods can be created on the fly.  For example, in Ruby, you can dynamically add a new instance variable to an object.  You can remove it too.  You can add a new method to the object.  You can remove it too.  There is no associated class with this object.

For example, you start off with an object that has no instance variables nor methods.  You decide it needs a name and a color, then you add a getName() and getColor() method.  There’s only one object in this “universe” that has these methods.  There’s no class.

Now, if you’ve only ever coded in Java, this seems like total chaos.  If you declare classes and create objects of that class, you know exactly what methods the object supports and which ones it doesn’t.  It makes it easier to track many objects, at the cost of losing dynamic type support.

Javascript isn’t a OO language.  It’s called a prototype based language.  Each “method” is really more of a function pointer, that associates a function name with the pointer.  You can reassign what this function pointer points to dynamically.  You can’t do this easily in Java.  You have to create function objects (strategies, etc) and have the method delegate to this function object.  You can get similar behavior, but it’s not as easy to do as in Javascript.

Once you discover other languages that have different ideas on OO programming (or languages, like Javascript, that provide alternatives to OOP), you begin to see that Java didn’t come up with the only way to do OOP.

Now, should you teach this to students?  After all, they don’t know OOP at all?  Is it wise to say there are a gazillion variations on a theme, and explain those variations?  I would say it’s not wise.  First, get them to master one OO language.  Once they have a solid grasp of some fundamental ideas, then begin to question the assumptions of the language.  However, until they have some idea what a programming language is, they’re not ready to see other ways the language could have been defined.

Why point this out?  Because you, the teacher, should be aware of these things.  It helps you think about the way you teach a language.  You might, for example, make a point of making sure students know what a class is versus what an instance is.

OOP is hard to teach because there are so many concepts, and because tracing code is far more painful.  Dynamic dispatch makes it really challenging to figure out what your code is doing.  In particular, if you teach C++, copy constructors, assignment operators, and destructors are being called all the time, often without your knowledge, unless you know the language really well.

Sometimes when you teach a language, you should ask yourself, why am I teaching this language in particular?  What’s so special about this language?  What are its advantages and disadvantages?

Questions Anyone?

Anyone who has ever taught a class invariably asks “Does anyone have any questions? If you don’t, I assume you understand everything.”

Mistake.

Believe me, it’s really hard to ask good questions. Most students never quite learn the skill. To ask a good question, you must be constantly engaged in class, and many students are passive. They aren’t thinking in class. In any class I sit in, I think of twenty questions, one right after another. Some aim to clarify. Some are fixing errors. Some I’m just curious about.

I’ve begun to realize that many students, especially out of high school, simply don’t approach lectures this way. I tell students that they should aim to think about ten questions or more per class, whether they ask or not. Learning to ask good questions is a hallmark of learning.

But why don’t students ask questions? Suppose you, a computer science person, sat in a class on philosophy, and they start using some term you’ve never heard of, say, phemenological. Maybe they discuss Kant’s view on this or that. Or you step into a math class, and they are proving some theorem on some abstruse topic. What question would you ask? You’re plenty puzzled, but you can’t even begin to form the right question. The best thing you can do is say “What are you doing? Why are you teaching this topic?”

To learn to ask good questions, you have to have a pretty good understanding of what’s going on, but be confused about some detail. For example, if you are listening to some Agatha Christie murder mystery, you have to ask “Wasn’t the butler out of the house, and yet someone saw him that day? How is that possible?”

If you can get students to realize that learning means “telling themselves a story that makes sense to them”. If they can’t explain what they are hearing to someone else, then they haven’t really learned it. It must make sense to themselves first. Asking questions then becomes a way to clarify details of the story to themselves.

Instead of asking students whether they have questions, you ask the questions. Ask something really simple from what you’ve covered. This means you should be able to ask good questions to students all the time.

For example, suppose I am teaching object oriented programming. I say that objects separate out data and methods. Data is hidden. Methods are the way to manipulate the object. Then, I write this definition on the board. Then, I ask “what are the two parts of an object?” I would expect the answer to be “data and methods”.

At this point, they may still be confused. I might say “I know you don’t know what data and methods are at this point. You are confused. I will try to unconfuse you. Imagine there is a robot, and the robot is standing on a chessboard. Here, I’ll draw a chessboard. Each position on a chessboard can be described using a letter and number. In addition, the robot can face one of four directions: north, east, west, south. In addition, each robot has some units of fuel.”

“The data regarding this robot is: where the robot is located, which direction the robot is facing, and how many units of fuel the robot has. That describes the robot, as far as I’m concerned. I don’t care what color the robot is, how much he/she weighs, what the robot’s name is, how it moves, etc.”

“Now, I can tell the robot to do one of several things. I can tell it to turn left 90 degrees, turn right 90 degrees, and move forward some number of units. Those are methods. These methods will also change the data inside the robot, but indirectly. Let’s start up a robot, and give it a sequence of commands.”

The students follow along, updating the state of the robot, and the direction.

Soon, they are curious about the robot, and now you say you’re going to implement parts of the robot.

Key to this explanation is an example students can follow that’s interesting, but not too hard to follow. This is how I would introduce objects first programming. By using a robot. Far more interesting than a bank account, don’t you think?

Instead of asking students to ask you questions (which you should still do), ask them questions. Give them examples of questions you’d ask if you were a student so they can get an idea of how to ask questions.

The lesson learned from this entry? Students find it hard to ask questions. Ask them questions instead. If they don’t get the answer, try to come up with new explanations. Answer it for them, and ask again.

Preparing for Class

When you’re starting to teach, the hardest part is prepping up for the first few weeks of classes. Some people can’t help it. They wing it. They wait until classes start to force them to start. I would avoid doing this as much as you can help it. Try to stay a few weeks ahead of the class if you can help it.

If you’re teaching a class where programming is an essential part of the course, then your first goal is to make sure the projects run smoothly. A course where projects run smoothly is one where the entire course runs smoothly. Lectures and exams are all secondary in a project course. If you have to prioritize, do so based on the projects. Students spend the most time on the projects, and they can be a lot of work to run.

Some teachers find projects so challenging to deal with that they repeat projects year after year, rather than deal with the stress of coming up with new projects each semester. While this cuts a break for you, it also means students have access to older projects, and you get stale with the project. I would try to come up with new projects as often as you can do them. They do not have to be significantly different each time.

The first time you teach a course, you should implement the projects as the students would. If you are expecting the students to use a particular IDE, you should get good enough at that IDE to teach it to the class. For C++, you might use g++ if you’re in UNIX land, or Visual Studio otherwise. For Java, Eclipse or some other IDE is a good choice.

Realize that an IDE takes some time to teach, and so you should practically think of it as part of the language. You teach loops, but you also teach how to structure projects within the IDE. You may need to write up documentation that describes the basics of using the IDE. Encourage students to add their own documentation if you run a Wiki.

If you have a teaching assistant, have them implement the project. Explain why it’s important that they do so (because they are trying to catch errors, because they want to be useful in office hours, rather than thumbing through the descriptions, etc). They can tell you if the project is too hard or too easy. Once you’ve taught the class a few times, you’ll get a better sense of how hard a project is.

Gauging the difficulty of a project is hard. If you have reference project descriptions used in the class from before, that will be helpful to develop a project. Some people make really easy projects (write a binary tree) and others make really hard ones (oct-trees, anyone?). I’ve written difficult ones and I realize that they were not worth it. They took up a lot of my time, as well as a lot of the students’ time. Realize that although students need to spend time on your projects, they have other classes. It was a lesson that I didn’t learn so well.

Implementing the projects will give you some sense of how hard it is. Expect students to take anywhere between two and five times as much time as it takes you, assuming you’re decent at coding.

Some people write extremely brief project descriptions. They don’t want to delve into details such as error handling, etc. Try to be precise where you need to be precise. If you are teaching Java, have them implement interfaces, and give them some sample unit tests to run against. I tend to prefer longer, more precise descriptions, but most people find it’s difficult to write more than two pages for a project description.

This is another reason you want a TA. The TA can read the project for you, and decide whether it’s hard to follow or not. You may even be able to get a colleague to look it over.

What about lectures? Most people plan for an easy first lecture. Cover the syllabus, and send the kids on home. I prefer to jump into material as soon as a I can, but the syllabus is suitably important to cover.

I would do the following. Quickly cover the main topics of the course. How many exams, etc. If you want to talk about cheating, you can do that. But I would break up the discussion of the syllabus over several lectures, hitting a key point each lecture, so students are more aware of the syllabus.

In the first lecture, go over what you want the students to learn, at a high level. For example, if you are teaching an intro course, you might say “I want you to be able to write a simple game by the end of the semester. By then, you should know what an interface is, how to write functions, loops, and understand the basics of object oriented programming”. I wouldn’t spend too much time talking about what you’ll cover in the semester, because it goes over the head of the kids.

For example, if you are teaching object oriented programming, start of talking about objects. What is an object? What is programming? Why did we pick this language? What is a language? Write a simple piece of code.

Even in your first lecture, you should be able to give an elevator pitch. Suppose you were meeting a colleague in the elevator of a tall building. You have three minutes to summarize what the students should have learned in class that day. I believe in setting small goals to cover in each class.

Indeed, as you prepare the first few lectures, write down a list of topics. For example, for programming, you might have the following list:

• what is an object?
• separation of data and methods
• what is data?
• what is a method?
• give an example! (robot on a grid)
• introduce syntax to a Java class
• cover basics of editing a class (have a handout, and webpage reference)
• begin to cover basics idea of testing

You may discover that some ideas you thought were really easy (say, looping through an array) are not easy for the students. Realize students can misunderstand even the easiest of concepts. I was told that students wouldn’t understand arrays. I couldn’t believe it. It was true, though. Students have a hard time with loops!

That lead me to emphasize tracing code. You can’t understand how important tracing code is. You tell this to someone who has never taught programming, and they are aghast when they discover students who don’t know the flow of execution in their own code. They need TAs to fix their code. They change the code at random. They find tracing to be extremely tedious, and one reason is that they such at it. With practice, they will get better, but it’s something you have to compel.

Indeed, I suggest teaching programming languages, at least at the intro level, much like real natural languages, i.e., through a lot of repetition on their part. Until a student can trace code effectively without a computer, they can’t easily code effectively.

You may discover that you can only cover so much in a class, and you’ll have to decide if that’s fine. Trying to catch up to meet a certain schedule may ultimately cause many lost students. In the meanwhile, you may also have to figure out how to give advanced students something to think about.

One way to do this is to propose a tough problem at the start of class, and see what ideas students get.

In the next entry, I’ll talk about asking questions.