One Instructor's Flipped Classroom Philosophy

Earlier this month, our Education Development Centre hosted a teaching round table on the flipped classroom.  At the session, engineering instructor Shermeen Nizami shared her philosophy for flipping her own fourth year undergraduate class.

Nizami began by sharing Rogers' diffusion of innovation theory.  She found this after her first flipped course was over, but felt it correlated well with that happened in class.  As shown in the below diagram, there are innovators, early adopters, the early majority, the late majority, and the laggards.  The distribution of these groups is shown in blue, while market share of an innovation is shown in yellow.  A question Nizami asked herself was who is in the chasm? Why do some students feel like the flipped classroom teacher is not doing her job? ("I want you to lecture to me!") For any classroom innovation to be successful, we need buy-in from students.

(image via Wikimedia Commons)

Why flip in the first place? In any given class, 30% of learners are apparently blocked; they can't be reached.  60% might be described as passive learners, and only 10% as active learners.  Could flipping help bring more students into the active segment? Is it worth it? It is if you believe that more students fail a lecture-based class than an active class, and that the rates of retention claimed in the learning pyramid are even close to accurate.

How do you flip? Nizimi says teachers need to look through the eyes of a student, and help students see themselves as their own teachers.  The mindset of both the student and the teacher need to be flipped. The teacher needs to be careful to keep students at the points of maximal learning: at the edge of their comfort zone, but not quite into the panic zone.

Design thinking gave Nizimi an useful model with which to approach her classroom:

• Empathize: validate the level of difficulty students face in class
• Define: gain students' confidence that you are on their side and not trying to trick them
• Ideate: involve students and come up with creative solutions
• Prototype: create opportunities for students to try out the proposed solutions
• Test: solicit student feedback; be brave

The round table ended before we got a chance to get into the meat of what Nizimi's students were actually asked to do before and during class, but I did appreciate the constant reminder that we should involve students in the learning process as much as possible.  Whether I get the opportunity to formally flip or not, I hope to keep that thought in mind in all my teaching practice.

Review / Ruby Wizardry: An Introduction to Programming for Kids

I think story is a powerful way to teach computer science.  I also think that too many programming books are boring.  Boring is fine for the experienced programmer looking to learn a new language, but maybe not so great for a beginner – someone we have a chance to hook onto programming!

Enter Ruby Wizardry, a book from No Starch that teaches basic Ruby concepts through a fun adventure story.  This is the programming book I've been waiting for!

Ruby Wizardry opens with a scene featuring the King and two kids from his kingdom, Scarlet and Ruben.  The King has lost his string, and needs the kids to help him find it.  Computing devices are all over town, allowing those skilled in Ruby to affect their surroundings.  From the public transit that runs on while loops to menus at the local eatery, it seems that Ruby is everywhere.  After finding the King's string, Scarlet and Ruben travel around town with the King, slowly uncovering some kind of devious plot that will be up to them to stop.

There are many things to love about this book.  The story is charming, and puts female characters at the forefront as competent programmers.  For example, the King himself is a bit of a luddite that tries his best to learn some Ruby along the way.  Meanwhile, his wife, the Queen, is "quite the hacker."  The conceptual content is embedded nicely into the story, and concepts are explained in an informal, conversational style.  I mean this literally – the characters are often teaching each other about Ruby, also allowing common misconceptions or admissions of not understanding to come up.  Everything you learn in a chapter is reinforced multiple times, and each chapter includes a mini-project and detailed summary.

There are some issues from a pedagogical standpoint.  Perhaps this is because the author of this book, Eric Weinstein, seems to have been educated as an author first and a programmer second.  There are certainly times when even I get lost in the Ruby syntax (I'm new to Ruby).  I don't think it's necessary to show four different ways to accomplish the same thing, especially when one of those ways is a lot easier to understand than the others.  The goal of a book like this is not to teach all of Ruby, but to introduce readers to the basic concepts of programming and set them up for success should they wish to continue learning.  It seems that this is forgotten at times.

Nonetheless, I am thrilled with this book.  I sincerely hope that more programming books will soon appear that use story or other contexts to deeply embed concepts into.  I think it's a great way to introduce anyone to programming, whether young or just young at heart.

(If you act fast, you can get a copy of Ruby Wizardy in this awesome No Starch Humble Brainiac Book Bundle!)