Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T09:46:05.817Z
Answers.LastActivityDate: 2017-06-06T09:46:05.817Z
Answers.UserDisplayName: Gypsy Spellweaver
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-04-10T15:37:57.317Z
Answers.Text: 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.
Answers.UserDisplayName: Ryan Deschamps
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T21:09:15.963Z
Answers.Text: As in, call one student to the front of the room and have them type some text that everyone can see?
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T21:37:37.230Z
Answers.Text: 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?
Answers.UserDisplayName: thesecretmaster
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T21:04:35.863Z
Answers.LastActivityDate: 2017-06-06T21:04:35.863Z
Answers.UserDisplayName: Susan Fox
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T09:27:33.187Z
Answers.LastActivityDate: 2017-06-06T09:27:33.187Z
Answers.UserDisplayName: vacip
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T19:05:25.830Z
Answers.Text: Nice link to version control.
Answers.UserDisplayName: Sean Houlihane
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T11:03:29.883Z
Answers.LastActivityDate: 2017-06-06T11:03:29.883Z
Answers.UserDisplayName: Miles
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T15:20:26.720Z
Answers.Text: +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?
Answers.UserDisplayName: Peter
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T16:02:18.777Z
Answers.Text: 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.
Answers.UserDisplayName: Ben I.
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-06-06T13:06:55.377Z
Answers.LastActivityDate: 2017-06-06T13:06:55.377Z
Answers.UserDisplayName: Ben I.
Body: <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>
  
Tags: <lesson-ideas><curriculum-design>
Title: Instructional Methods for In-class Code Demos
ThreadText: # 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 username_2 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.  
  
  ---
  
  