What makes for good CS PD?

I have had the opportunity to experience a lot of PD over the last few years with KSTF and the huge surge in support for CS.  After attending Upperline Code's teacher workshop, I have been wondering what makes for good CS PD?

Good CS PD should put the teacher in the role of a learner.  I saw this in my EDC workshop in Mathematical Practices, in Upperline's Workshop, and at code.org.  By having teachers fully engage in a structure or routine for a CS classroom, they can better implement it in their own classes. ....

Good CS PD should have participants planning and teaching lessons.  This seems like a no-brainer to me now, but I will admit it wasn't always that way.  Just like a "good math class" should have students "doing math", good teaching PD should have participating teaching.  In Upperline, we co-planned and taught our lessons which was necessary from a time-saving perspective, but also helpful as we got to collaborate with other teachers and bounce ideas off one another as we planned.

Good CS PD should have a common language.  Whether it is talking about engagement, access, problem solving, abstraction, computational thinking, once we are able to have a shared vocabulary around what we are talking about, we can go deeper into these conversations.  Sometimes this shared vocabulary can become meaningless buzzwords, but I still think bringing some kind of awareness to our goals through establishing a common vocabulary gives all participants more opportunities to contribute.

Good CS PD should have a time to be reflective.  With Upperline, after we taught a lesson, we had a time to reflect on the lesson we just delivered and got feedback from the participants.  I think the feedback part was hugely helpful for me but I wonder how other teachers would respond, especially if there are teachers who aren't psyched to be there.  I think I assume that every teacher is as excited to be at PD as myself, so I forget that there are people who were "volun-told" to be there.  I know there are other ways to reflect on the lesson after it is delivered - by shifting the focus to reflecting on the lesson from the learner perspective or considering how students would react in the lesson.  Regardless, having time to reflect on the lessons helps me think about how I would apply what I saw in my own classroom.

I realize that many of these ideas aren't ONLY for CS PD, but really good practices for good PD in general.  

However, while these guidelines are all well and good, one of the biggest questions is what does the content for CS PD look like?  I have attended many CSP PD workshops (for code.org, CS50, or Mobile CSP) but they all center around the same content.  They focus on one curriculum's interpretation of the AP CSP standards.  When I have attended the EDC's workshop on Mathematical Practices (MPs), we learned how to incorporate MPs into any math course we were teaching from 6th grade math to 12th grade math.  I am wondering if we can do that for Computational Thinking standards.  Is that valuable for CS teachers?  Can we do a 2-4-1 and learn CS content (like, data science) AND computational thinking?  Is that, as the kids say, "doing too much"?  I acknowledge it is difficult to tell a teacher to develop a lesson plan on cyber-security without the teacher really knowing cyber-security, but maybe just giving teachers a direction is enough.   

In the Upperline Workshop, the CS content was all around web development.  We covered HTML, CSS, Ruby, loops, conditionals, etc.  At one point I was supposed to teach p5 - I realize that this is a broad thing to teach, but my partner and I narrowed down our specific goals for the class and then developed a task we wanted students to work towards in the class.  This practice was actually really useful.  I think you could do that with other CS topics as well - cyber-security, data science, etc.

Even while I hope to be able to teach some of the content I learned at Upperline in my CS classes, I expanded my own content knowledge in CS by participating in other teacher's lessons and experienced multiple ways of approaching CS instruction - some ways I liked and others that wouldn't fit my teaching style.  For me, as a teacher who is ready to further develop my own approach to teaching CS, having this experience was really valuable.

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

Day 3 PD reflections: What story am I telling?

A few things have me thinking about the idea of story - a colleague and I had a little conversation about this during the school year, KSTF has us talking about the power of teacher stories, and what I am learning at Upperline PD has me thinking about the story each lesson tells while teachers are teaching their sample lessons.

Now I am wondering, how does each unit I have tell a story?  How do my lessons weave together a content story for students?  Is there a story arch throughout the year I can hang units and lessons on?

More recently, I have been thinking of the role of stories and learning targets in different types of lessons.

Traditional Instruction

When talking about traditional instruction, I think the story still needs to be there and learning targets provide key pointers at the beginning of the lesson to tell people where we are going.  For example, the move "The Breakup" is about, and results in, a break up.  You can still tell a good story if you know the ending.

In my upperline PD, I realized that if a teacher was teaching in a traditional way, I wanted to know exactly where we were going in their story.  I saw it needing to know the key checkpoints along the way.  It was somewhat like peeking ahead to the titles of future chapters in a book so I could see the story come together.

In traditional instruction, the teacher is the story teller.  Every student gets the exact same story from the same deliverer. Some teachers tell stories better than others here and I think there are some tricks to make the story still compelling for students.

• I have noticed when ever I am super excited about the content (even if in reality I am not super jazzed about it), students engage more.  Seeing story tellers excited about the story is one way to get buy-in from students.  
• Making the story feature key characters that are interesting to students gets a giggle from kids.  Including references to fidget spinners, Shakira, whatever is trendy or and inside joke at the moment includes students in on the story.

I get that some days even the most constructivst teacher needs to go to traditional methods of teaching.  That's OK.  That's not an excuse to forget about the story you want to tell or to skip a good hook. 

I wonder how else strong traditional instruction teachers are able to engage students in their classrooms.


Discovery/Inquiry Based Instruction

Inquiry based learning puts the student at the center of the story.  It also means that you might have 36 different stories being constructed in the classroom during a lesson.  Thus, it is the teacher's role to weave these stories together to make the picture clearer for all learners.

I truly believe that to give students the learning target at the beginning of an inquiry based learning lesson, you give away the punch line.  It's less fun to explore if you know how the story ends.  In fact, why explore, why take risks if you know the ending.

In discovery based learning, the storyline of a class is revealed by students and through students work.   However, I think we have all read something where the story wonders for too long (perhaps this blog post is one of them).  That's why the teacher is the ultimate architect of the story in these classrooms.  Being able to predict student questions and responses and guiding them to the "a-ha" moments takes a different set of skills.

What I would do differently next time - Using Arduinos Part 3

Knowing what I know, now, here is what I would do differently next time:

1. Display the projects when they are done.  Again, I need to show the school what we are working on.  I think this would also force students to clean up their work and take more ownership of what they did.
2. Get more supplies, specifically more battery packs, sensors, and box cutters.  The battery packs can be used so that the boards don't need to be plugged in.  Students who wanted to make cars needed to be untethered.  Also, I ended up also purchasing a re-sealable mat but I need more box cutters for students to be able to cut cardboard and plastic.  The sensors would also allow students to make more interactive projects.  I like the idea of the projects being interactive rather than just movable.
3. Assign one group a kit.  I didn't do this the first time around and it got messy.  The boxes got messy and there was no one to take responsibility.  The second time around I had students put a piece of tape on their box and write there name on the tape.  It made organization SO MUCH BETTER!
4. End with a "scavenger hunt" - really just to trick students into cleaning up.  I would make a mat with each of the items the box SHOULD have in it and then have students show that everything was in there to "check in" their materials so it would be ready to go for the next group!

Overall - it was a success!  I am definitely going to do this next year.  I am hoping I might be able to collaborate more with our engineering teacher to better understand the circuitry component - I think I am making a dent in it, but expanding my knowledge would be a good thing. 

What does CSed Community 2.0 look like?

One of the main goals in our code.org PD is to build a CS community.  I think that happens at TeacherCons and at week-long PD.

But, the big question is, what next?!

1. How do we sustain this community?
2. Where do we continue to build these connections?  Twitter?  A forum?
3. What does the community need to be successful?
4. What are the goals of our community?

... alright, this is reminding me of KSTF's systems frame work...

(after a bit of Google Drive Digging)

I love the quote I got from a KSTF meeting a year back that "each system is uniquely designed to get the exact result it is getting".  I certainly need to unpack the system here for our CSed community on a national and local scale.  I'm writing that on my "blog-to-dos" now...

I still think the model of an inclusive ed community comes from MTBoS.  I really think the success of MTBoS has come from a few rock stars just rocking.  They blog and share their experiences really freely.  They take risks in their classrooms and share the results.

In talking with one of the participants at the Upperline Training, he mentioned that CSTA feels really inaccessible to many teachers.  It is expensive.  Even presenting at CSTA is cost-prohibitive for a lot of teachers which MAY result in having less strong sessions.

I look at MTBoS's solution to not having a space to celebrate their community in Twitter Math Camp.  It is wildly successful.  CS needs to get the right "whos" in place, but I think we could get there.

Right now, we are just trying to build capacity and get more CS teachers, but once we have CS teachers, how do we continue to support them?  It takes a bit of time, but how can we amplify voices of CS teachers and draw them into the community?

I would love to see CS have their own "CS" Twitter Camp as a place to build their national community.  I suppose the first place to start is local.  Right now, one other teacher and myself meet up monthly to talk about our classrooms. It is an awesome collaborative time.  I have learned a lot from him (and hopefully he has learned something from me).

My goal next year: To open this up wider.  Invite more teachers to grab a drink and talk about CS ed.  If I can do one in the fall and one in the spring, that would be awesome.  I think I want to focus on HS CS teachers at the moment, but I certainly want to grow it from there.

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.

Kenetic Light Sculpture Project - Using Arduinos Part 2

The task I gave students was to do one of 2 things:

A) Create a kinetic light sculpture - literally, it just needed to move and have lights

OR

B) Create something that is useful for the school

I anticipated push back from my boys about having to do "art" in my class, so I wanted to preemptively strike and give them a second option (thus plan B was born).  That was hugely successful.  Most my boys realized that making something move and light up was not the end of the world.  In fact, several of them moved this to more of a "robotics" project where they had a car that could drive.

To do this, we had a lot of materials, generously supplied by a KSTF grant - here were just a few of them.  My full list of items can be found here (note: make sure you filter and sort in the top right corner for purchased AND unpurchased items to see them all).

Also, essential to this project were extra items I got from SparkFun - like motors, jumper wires, more LEDs, etc.

It was interesting to see students start with nothing, develop an idea, and then implement it.  It really pushed them to think differently about programing, circuitry, and problem solving.  During the week, a colleague of mine, Ryan, came to visit my room.  He comes from a science background so he had a different perspective than myself.

It was SO AWESOME to have him there.  I have been excited about what my students were doing and it was so fantastic to get another perspective!  Ryan mentioned that he noticed students had missed the fact that once their spinning motors started spinning, they were going to run into a physical restraint with the wires also getting twisted.  I hadn't anticipated this issue myself either.  Ryan also pointed out that engaging students in the engineering design process earlier in the project could be helpful.  Even doing a hypothetical engineering problem (OR BETTER YET... one of code.org's CS Discoveries problems from their problem solving unit) could help students develop a more coherent plan to start with.

I had given students a project organizer as a starting point, but it was really insufficient and didn't address the new issues that would arise in this project.  I reached out to our engineering teacher to see what he used - in hopes of being consistent throughout courses and he sent me this.

The end result was a lot of different projects.  Here are a few of them:

Movable light sculpture - just need to get him free from the wires! #mvhslearning pic.twitter.com/7koBBYa3Pp

— Kaitie O'Bryan (@Kaitie_Obryan) May 24, 2017

Spinning solar system is in progress #APCSP @SparkFunEDU pic.twitter.com/9v6tap6oHK

— Kaitie O'Bryan (@Kaitie_Obryan) May 31, 2017

It's a floor sweeping robot with an angry driver... of course. #apcsp pic.twitter.com/JsFq2U73T2

— Kaitie O'Bryan (@Kaitie_Obryan) June 5, 2017

Day 1 of NYC PD

After day 1 of my NYC workshop, I have a few big take aways:

1. Thinking about the zones of learning is useful for teachers AND students!  Eventually we want students to be able to design their own learning in the real world and that means helping them monitor their own learning.  Danny's model of different zones of learning, and also thinking about them as a range that we slide into in different times made a lot of sense to me.  He also talked about needing to get students be able to self-monitor where they were in these zones so they could manage their learning over time.  This including asking students some questions:
   • If they were in the "comfort" zone, are they taking enough risks?  Do they need a different task?  How could they modify their project themselves - what would be a "reach" for them?
   • If they were in the "panic" zone for much of class, they really should ask for help.  Knowing when AND how to advocate for yourself is important for students to know and be able to do.
   • We want the "learning" zone to be BIGGER!  To make it bigger, we should try to operate on the edge of panic (this actually perhaps explains my personality a bit).  Operating on that edge "pushes" your learning zone to expand.
   
   
   
    
2. I need to build a "Whole Class Culture".  I was so much better at this in the math classroom.  I think it was because I forced students to work with people who were unlike themselves.  Teaching an elective class, and a class with a large gender imbalance makes this rougher.  My goal is to really make this happen for my AP CSP class (after the drop period, that is).  There was nothing wrong with my class culture last year, it is just that students didn't branch out socially and I think doing this occasionally is important.  I can do this simply by having people pick ONE partner they want to sit with, and then mixing up the pairs into groups.  I also need to think more intentionally about the following:
   • What beliefs do I need my students to have in my class?
   • What habits do students need in my class?
   • What workflow needs to be in place?

---

My favorite quote from today:

"Our natural state of being IS not knowing"                                                                                         - Danny

---

Also, fun fact: After doing the pre-work for this PD, I have gained more confidence in being able to do HTML.  The hr above and some of the formatting I did in the HTML composure screen... successfully!