Tuesday, July 4, 2017

Lessons learned from day 2 of PD

Today we started observing two lessons in our Upperline training.  From watching other teachers teach, here is what I learned:

  • Give the compelling why.  My district internally uses the "compelling why" phrase a lot, but here I thought about using it with students.  Dan Meyer talks about creating the headache so students want the aspirin (the tool to fix the problem) - it is much of the same reason here.  I think when a good hook (a story, an analogy, an unplugged activity) is difficult to find for a lesson, that's ok, just make sure that there is a compelling why for the content.
  • Get students to google commands.  Giving students a command that might be helpful, without showing specific examples, is OK - welcome to the real world!  Googling things is totally ok.  Encourage it, plan specific times in your lessons/labs where you want students to practice the googling skills AND model it.  Students don't always know what to google when you tell them "google it".
  • Model pair programming.  And then, tell students you are modeling what pair programming looks like.  Two teachers did this today in their lesson and I really liked that idea.  I would want to also model what that dialogue looks like from students.  Again, what types of behaviors do I want to instill/encourage?  I don't want students to just grab away the keyboard when they get frustrated with their partner - modeling this dialogue before having students pair program can help with the frustration level. 
    • We did a "daggar, falcon, spaghetti" exercise today to help students see that it is on THEM to communicate to another person in the class.  If the message doesn't get through, they need to try again.
  • Academic dishonesty in CS.  Someone brought this up.  If students are not being honest about their work and code in class, why is that?  Are we giving too common of assignments? Do students not have enough freedom or skin in the game?  I think I need to have very clear expectations for why students should not cheat.
  • Team builders/icebreakers.  We did a ton of these, the name/action/adjective game, the "Wah" games, the "stretch and share" (totally could use that in a small scale - someone names a stretch and then answers a question like "how are you feeling" and then the next person names a new stretch and answers the question), rock paper scissors evolution style (where you start out as an egg, chicken, and then raptor).  I get them.  I like them in theory, it seems like I would have a hard time getting students to buy-into doing them in class.  I ask my students to do a lot.  Will this be too much?  OR will it open them up to taking more risks?  I might be able to do it on a day we have class meetings or half the class is gone for testing or something, but... I think the value in doing it is early on.  It certainly would help students get to know eachother, but does it help me build capital or do I use capital in doing these games.  I don't know... I might use them in my concepts class... I have to noodle on this a bit.

No comments:

Post a Comment