Feedback is golden

Last week, our class read a New York Times article about the flaws in the American education system, particularly in the way we teach math. We keep changing our standards for students, but a major reason why we still aren’t able to achieve as much as students in other countries is that we don’t teach our teachers how to properly incorporate the new standards into their classrooms.

What I found most interesting was that in Japan, teachers have jugyokenkyu, which literally translates into “lesson study.” A teacher teaches a lesson in front of students, other teachers, and at least one university observer. Afterward, the observer discusses what happened during the lesson with the teacher. Each public lesson offers an opportunity to test out a new hypothesis, a new idea on how to help children learn. The discussion allows the observer and teachers to reflect on how successful the hypothesis was.

I just got back from Day 3 of Code It, and I couldn’t help but think how our mentor feedback system is similar to jugyokenkyu. Because I am essentially creating the curriculum for Code It for the first time, everything I do is testing out a hypothesis. I choose certain concepts and projects to teach based on my own personal experiences, but what really makes Code It successful (in my own eyes) is the continuous feedback from all the mentors.

After each Code It session, mentors stay around for a quick debrief. Last week, the mentors were in overwhelming agreement that the pace was too fast for the girls. A lot of the girls fell behind, which put a lot of pressure on the mentors to explain everything again to each of the three girls they were in charge of. To solve that problem, I made three changes for this week:

  1. Post-It system. Girls who were falling behind would stick a Post-It note on the back of the computer so that I would have constant visual feedback on who needed more time.
  2. Mentor hand-raise system. Rather than have the girls raise their hands if they needed more time, I would check in with mentors directly. If the mentor had any girls who were struggling, she would raise her hand to let me know.
  3. Breaking the barrier between me and the mentors. This one is rather simple. I just let the mentors know that if at any time I was going too fast, they should just say, “Hey, Kelsey! Please stop.” And I really will stop.

I think the general consensus for today was that the pace was much better. However, I still received additional super valuable feedback from the mentors. For one, I learned that the girls who did fall behind today fell behind because they were still sampling the different sound selections even after I had moved onto the next instruction. Together we decided that next week, I should tell the girls which sound to select and simply tell them that they could go back and customize it later.

This week, I also tried out a “scavenger hunt” type deal where I would show the girls the desired end product and ask them to write the code to create that end product. One of the mentors pointed out that some of the girls struggled to remember what the end product was, so it would have been better if I kept the end product on the board. Next week I’ll write out the specifications of the desired end product, so they have that to reference.

The key takeaway from today’s session is how valuable feedback is. I’m so lucky to have about nine mentors helping me out each weekend because I constantly have feedback on how I’m doing. A lot of teachers don’t have that luxury, so I’m grateful that I can get immediate feedback on ways to improve.


First adventures with Code It

This year I decided to take on the challenge of designing and teaching curriculum for Code It, a program that teaches middle school girls how to code. It’s been quite the adventure sifting through all the computer science resources available online and selecting ones that I want to use. So far, we have had two sessions, and already I have learned so much about teaching an actual class.

During the first session, I had originally planned to walk the girls through making three basic apps on MIT App Inventor. On the morning of the first class, I was really excited about using App Inventor until I realized that I made the rookie mistake of not having the phone emulator application downloaded onto the computers beforehand. Because we were using school computers, I didn’t have administrator’s privileges to install the emulator myself. I had a huge panic attack, but luckily I was able to contact the person in charge of the computer lab space. After I downloaded the disk image file onto all 24 of the computers, the tech consultant was able to remotely install the emulator for me. I was so, so, so grateful for his help, especially because it was a Saturday morning. Lesson learned = Make sure you have all the required materials and resources ahead of time!

After resolving that issue, I thought I had overcome the biggest obstacle (at least for that day), but I was wrong. Out of all the possible times that MIT’s connection to Google servers could break, some external force decided that the best time would be right when I was starting MIT App Inventor with the girls. Long story short, we weren’t able to use App Inventor. I quickly improvised and pulled together a mix of icebreakers and an unplugged activity to fill the remaining time. Luckily, I think it went considering the situation, but I’d imagine the girls were disappointed that they were unable to make their apps.

Right from day one, I learned that Murphy’s law still applies to teaching: Anything that can go wrong will go wrong. I guess that’s just one reason why teaching is such an adventure!