Instructional Methods for In-class Code Demos

Question

When demoing code in class, I have tried at least three different methods of instruction:

1. Write code live and have students type along

2. Write code live and have students follow my logic while only I type and narrate my thinking

3. Start with a full working demo and analyze an already written program

In all circumstances students can access the programs on GitHub after class. Moving forward, I would like to develop a more consistent and effective approach.

What instructional methods are most effective for teaching with sample programs?

Answer 1

I think this depends on the curriculum and goal. If the goal is not to teach them specific algorithms, but to teach them problem solving, then have them write the code first. I come from adult education, and this approach works fine there for me.

What I do is I give gradually more complex exercises, and give them time to develop a solution. I also give them a few keywords, commands that they will likely need. I go around and help with individual solutions. They are allowed to work together, communicate, help each other if they want to. They can use the help, internet, the course book, whatever they can get their hands on.

This means a lot more work for the teacher, as you have to run around, understand different approaches, and not force your solution on them.

If I find a particularly good or interesting solution, I show it to the class (after everyone has finished).

I only solve the program in front of the class once everyone has a solution. (Pretty disappointing, but even this way I see some of them just delete their working solution and mindlessly copy mine.) I always try to emphasize there is no one good solution. There might be better, faster solutions, but as long as theirs is correct and works, it is a good solution.

As for the inevitable speed differences in the group, instead of giving one exercise, I give 3-4. The first is the mandatory, the rest is extra. (Maybe for + points or such to motivate them; luckily in adult education I don't need the extra external motivation.) When the last person finishes (or gives up) the main exercise, that is when time is up.

So I say the most effective way for teaching with sample programs is let them try, fail, suffer, find their own way, then finally succeed. Don't spoonfeed them.

Answer 2

All of those tools are useful, and for slightly different things.

1. Write code live and have students type along

   This is a great tool when you want to discuss a simple algorithm. Having the kids type prevents them from completely zoning out, and it also gives them a first check in understanding the algorithm.

   One thing that surprised me when I first started doing this was that kids who don't understand what you've written often make typos at this stage (sometimes rather odd ones), and have to raise their hands for help getting theirs to compile or run correctly. Having to deal with typos and such gives you an immediate sense of who needs help, and keeps the kids engaged.

2. Write code live and have students follow my logic while only I type and narrate my thinking

   This is a perfect tool for illustrating debugging techniquss and common errors. This tool is effective a time you want to do something foolish before showing the students how to fix it.

3. Start with a full working demo and analyze an already written program

   This is a great option when you want the kids to get the gist of an algorithm, but don't care if they get all of the details yet. I will often do this when I am starting a complex algorithm that I intend to do in several passes, or if my only goal with the algorithm is exposure.

I would also add a 4th option, which is the one I actually use most frequently:

4. Create starter code together (as per #1), and have the class go off and try to figure out how to implement the next step of the algorithm on their own before doing it together.

   Going back and forth in a "student-tries, teacher-models" manner keeps the kids deeply engaged with the algorithm all the way through the lesson, as they are thinking through the problem (possibly with the help of a neighbor), and then coming back to you to see how they did.

Answer 3

There seems little value in students copying code off a display, but much in watching the teacher model how they think about the task, talking through the problem solving process of coding, as well as debugging (in the case of, ahem, deliberate, mistakes), iterative development and refactoring. I think this works if it's editing a longer program or writing short examples.

I'd say good practice would include sharing the code produced, via Github or elsewhere, as well as screencasting the talking through of the development process itself.

Answer 4

A good method will involve all three modes, in combination with each other. The mode will depend on the objective of the demo and the size of the code. If the students are not touch typists, there's going to be some, possibly hard to spot, errors, and entering a 50 line code segment will take a significant portion of the available time.

For small, basic sections of code, having a type-along can work. Especially if you're inserting segments, and changing parts, as the design evolves. You won't want to have them constantly typing the same basic parts every time you do a type-along session, however.

In some cases, you might want to do a larger demo of the small code. First is them watching you do the work, as you demonstrate some concept. Second, you do a type-along demo, where they help demonstrate the concept just learned from the solo demo, as the class writes a second piece collectively. Lastly, as lab, they apply the concept to a third code, following a problem statement you give them, but they develop the solution themselves with minimal guidance from you.

For moderate sized code, have the skeleton pre-typed, and available for download before the lecture, then work through the section that is the target of the class session. Concepts that have already been mastered need not be retyped each session.

When you get to the point where you are re-factoring code, or combining previous sections with new content, you can have that available for download as well, but do the demo without them typing. While doing the demo, you should also limit your typing. Have what you want to type ready, and to a copy/paste of the proper blocks. They presumably will be familiar with the concepts in the smaller sections, and the the objective is combining them to create a larger concept.

The last version is to distribute completed code for them to analyze, except that it's not fully working code - it's broken. The task is to find the error using the clues the compiler/interpreter gives. Of course, that means trying to design broken code that fails the way you want it to.

Answer 5

I have also experimented a bit with having a student do the typing that is displayed to the class, following my instructions. Student chosen at random. This can be a good way to assess how well the students are following what you are saying, and how well they've internalized the syntax and rules needed for the example. Just need to keep it fair and maybe avoid students who you know are really struggling...