Saturday, July 8, 2017

Day 4 of PD reflection

This one is going to be a bit more a "stream of consciousness" reflection... hold on to your pants.


  • I need students to move at least once an hour.  I really liked the mind meld icebreaker idea where students find a partner elsewhere in the room (standing) and choose a word (separately) and then say it out loud.  They need to try to match the same word over time.  For example, if one person says "hamburger" and the other person says "wonder woman" you need to try to think what is half way in between those two.  It's fun, simple, etc.
  • I have seen two different approaches to teaching objects.  One with Dan Shiftmann's processing materials (which were good) and then the one today where Jolson used video games to frame the topic.  I am always reluctant to use video games in CS because of the stereotype issue but... this is how it went.
    • Say we have a video game where we have a character
      • What Attributes might they have (which ones are getable and which ones are setable)
      • What Actions might they do (methods)
      • What "other" things might be important
  • Helping students brainstorm their projects:  Danny warned us against letting students get too attached to a single idea early on.  For this reason, the idea-ation portion was broken up into rapid-fire brainstorming where there were "no bad ideas" - everything got written down.  The general flow went like this with each question taking just 30-45 sections to brainstorm:
    • Who is your audience? (brain storm many, focus down into 1)
    • What problems do these audiences face? (brainstorm many, focus on 2)
    • What how can you help solve these problems? (brain storm many, focus on 1)
  • Scoping: Introduce the idea of MVP early on in the course.  These projects can go on forever.  This goes along with iterative and incremental development.  Have students think what the Minimum Viable Project looks like and work towards this first.  I like how this can be introduced early in the year.  I hope that this helps mitigate some of the perfectionism that arises, especially with female students.  If they see that small successes matter, that is important too. 
  • Hooks - do it. My professor at the U also required us to have decent hooks in our lesson and it makes so much sense.  It is also important to remember that hooks don't (and shouldn't) take up a lot of time. Hooks are there to just get every student into the lesson - they are there so the first 30 seconds of class brings everyone in.  
    • A story
    • A pain-point (aspirin)
    • What the end project might look like
    • A google search/funny video/topic
    • Quick brainstorm of student-relevant topics (what is your favorite movie - and then use that to talk about databases).
  • Spend time on "ta-da" moments.  It takes a while to get to these ta-das, I need to pause for the reveal and really make sure EVERY student sees it.  Sometimes I run through it a bit too fast and if students blink, they miss the "why" behind the lesson.  I need to pause in these moments, replay the "before and after", and make sure students see why they the "aspirin" is helpful.
  • Take time to look at errors and documentation. That's right, I think we want to over-teach a bit in CS.  Giving students the tools to answer their own questions is hugely important.  From what I gather, that's what the real-world does in CS - you google a TON.  I need to get students to look at and read the documentation.  I wonder if some of Nancy Johnson's reading skills could be helpful here.  Technical reading is different from what they are used to.  I am just thinking there are probably different skills involved - you don't read everything, you skim, you look for the code, you look for examples... I need to do more thinking about this.  Similarly, when it comes to reading errors, I need to have students develop skills needed to tackle these.  Some ideas mentioned were
    • read the errors out loud
    • ask students to summarize what they say
    • identify key parts
  • Answer questions by exploring the question.  Try it out (what if we use a different word, what kind of error do we get...).  OR try googling it.  SHOW. Don't TELL.  Model lead learner.
  • VOCABULARY.  In Upperline they use a lot of "anchor charts" to go over key blocks of of code.  They post these on the walls so all students can go back and see them later on if they cannot remember what is going on.  I am also wondering how I can support students in building vocabulary in my classes.  I wonder what my culturally responsive teaching book would say about this too...  Here is an example of what an anchor chart might look like. 
  • Show syntax - you shouldn't do "inquiry" on syntax.  It becomes too much of "guess what is in my head" types of questioning.  You SHOULD probe logic and "what-if" type situations - that is the part to push students and engage in higher level thinking. 


Finally, I realized I need to go back to my web development course to understand where JavaScript plays into all of this.  I think now that I have seen

No comments:

Post a Comment