<p>A good <em>method</em> 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.</p>

<p>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.</p>

<p>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 <em>help</em> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <em>broken</em> code that fails the way you want it to. </p>

CC BY-SA 3.0
2017-06-06T09:46:05.817Z
2017-06-06T09:46:05.817Z
Gypsy Spellweaver
<p>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...</p>

CC BY-SA 4.0
2024-04-10T15:37:57.317Z
It's exactly as Susan says. You get a student to do the coding and the class supports them through whatever specific problem you are trying to solve. This helps to identify any common configuration problems, misconceptions, cross-platform or other issues and it's super helpful when there's a Bring Your Own Computer (BYOC) lesson. It ensures a good pacing and It can also be helpful for students to see the kinds of errors that occur when you are solving a problem.
Ryan Deschamps
CC BY-SA 3.0
2017-06-06T21:09:15.963Z
As in, call one student to the front of the room and have them type some text that everyone can see?
Ben I.
CC BY-SA 3.0
2017-06-06T21:37:37.230Z
To me, it's unclear what you are having the student do. Are you choosing 1 student at random and only they have to type what you are typing? Or is everyone typing, but one students work is displayed?
thesecretmaster
CC BY-SA 3.0
2017-06-06T21:04:35.863Z
2017-06-06T21:04:35.863Z
Susan Fox
<p>I think this depends on the curriculum and goal. If the goal is <em>not</em> to teach them specific algorithms, but to teach them problem solving, then have <strong>them</strong> write the code first. I come from adult education, and this approach works fine there for me.</p>

<p>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.  </p>

<p>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.</p>

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

<p>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 <em>one good solution</em>. There might be better, faster solutions, but as long as theirs is correct and works, it is a good solution.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-06-06T09:27:33.187Z
2017-06-06T09:27:33.187Z
vacip
<p>There seems little value in students copying code off a display, but much in watching the teacher model how they <em>think</em> 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. </p>

<p>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.</p>

CC BY-SA 3.0
2017-06-06T19:05:25.830Z
Nice link to version control.
Sean Houlihane
CC BY-SA 3.0
2017-06-06T11:03:29.883Z
2017-06-06T11:03:29.883Z
Miles
<p>All of those tools are useful, and for slightly different things.</p>

<ol>
<li><p><strong>Write code live and have students type along</strong></p>

<p>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.</p>

<p>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 <em>(sometimes rather odd ones)</em>, 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.</p></li>
<li><p><strong>Write code live and have students follow my logic while only I type and narrate my thinking</strong></p>

<p>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.</p></li>
<li><p><strong>Start with a full working demo and analyze an already written program</strong></p>

<p>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.</p></li>
</ol>

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

<ol start="4">
<li><p><strong>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.</strong></p>

<p>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.</p></li>
</ol>

CC BY-SA 3.0
2017-06-06T15:20:26.720Z
+1 for #4. I like that idea a lot. Will definitely add that to the repertoire. Do you distribute that starter code via GitHub in advance?
Peter
CC BY-SA 3.0
2017-06-06T16:02:18.777Z
I haven't done that yet, but I possibly have not taught algorithms large enough to make it worthwhile.  So far, I have only pre-distributed code for labs.
Ben I.
CC BY-SA 3.0
2017-06-06T13:06:55.377Z
2017-06-06T13:06:55.377Z
Ben I.
<p>When demoing code in class, I have tried at least three different methods of instruction:</p>

<ol>
<li><p>Write code live and have students type along</p></li>
<li><p>Write code live and have students follow my logic while only I type and narrate my thinking</p></li>
<li><p>Start with a full working demo and analyze an already written program</p></li>
</ol>

<p>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. </p>

<p>What instructional methods are most effective for teaching with sample programs?</p>

<lesson-ideas><curriculum-design>
Instructional Methods for In-class Code Demos
# Instructional Methods for In-class Code Demos

(Asked by: username_0 on 2017-06-06)

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?

**Tags:** lesson-ideas, curriculum-design


---

## 5 answers

### Answer by username_6 on 2017-06-06. Score: 4

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 by username_4 on 2017-06-06. Score: 4

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.

> **Comments:**
> **username_0**: +1 for #4. I like that idea a lot. Will definitely add that to the repertoire. Do you distribute that starter code via GitHub in advance?  
> **username_4**: I haven't done that yet, but I possibly have not taught algorithms large enough to make it worthwhile.  So far, I have only pre-distributed code for labs.  

---

### Answer by username_7 on 2017-06-06. Score: 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.

> **Comments:**
> **username_8**: Nice link to version control.  

---

### Answer by username_1 on 2017-06-06. Score: 2

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 by username_2 on 2017-06-06. Score: 2

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...

> **Comments:**
> **username_4**: As in, call one student to the front of the room and have them type some text that everyone can see?  
> **username_5**: To me, it's unclear what you are having the student do. Are you choosing 1 student at random and only they have to type what you are typing? Or is everyone typing, but one students work is displayed?  
> **username_3**: It's exactly as Susan says. You get a student to do the coding and the class supports them through whatever specific problem you are trying to solve. This helps to identify any common configuration problems, misconceptions, cross-platform or other issues and it's super helpful when there's a Bring Your Own Computer (BYOC) lesson. It ensures a good pacing and It can also be helpful for students to see the kinds of errors that occur when you are solving a problem.  

---

