As educators, we’re lucky enough to be the people that motivate students to love the subjects we teach. At the Flatiron School Pre-College programs, we think about this fanatically. It’s our responsibility to get our high school students to learn to love to code.
We teach many types of students. Some come in having written advanced Python scripts, and some come in never having written a line of code in their lives. How do we build lessons that engage these varying backgrounds? How do we build lessons for students who haven’t been exposed to – or are on the fence about – learning about software development? How do you write and deliver curricula that not only teaches kids to code, but also imbues a love of the art of writing code? Here are a few thoughts.
Programming should be accessible to everyone—no matter what they do for fun- so let what kids love help inform what you teach. That means being flexible enough to run with the examples your students give you. It’s not enough to come in to class, stick to a predefined script, and expect them to be captivated by the material. When teaching object orientation in Ruby, we prompt students for games they play and then build out models that simulate the way these games work. Not only does this keep the students excited about the code up on the screen—it also keeps teachers on their toes.
High school students love a challenge. The labs we’ve developed at the Flatiron School are intentionally designed to support our students in their learning, while keeping them outside of their comfort zones. Our introductory Ruby class challenges involve building methods to convert temperatures from fahrenheit to celsius, developing a spotify-style playlist object, and writing code to encrypt text. We help students along the way, but also make sure that they relish in the challenge of solving a tough problem.
We focus on building community and friendships as part of the process of learning to code. It’s not enough to encourage students to get to know each other before and after class. Our labs and challenges are purposefully designed to be completed in teams. When teaching HTML and CSS, we have students design each other’s portfolio or profile pages, as opposed to their own. It’s not uncommon in our classes to see a group of three of four students debating the best way to structure their applications, brainstorming features to add to their programs, or debugging each other’s code. To this end, we’ve arranged our classroom to maximize student interaction and pair programming: whiteboard tables seat four students and have group monitors for code sharing.
One of the issues with our traditional education system is that teachers expect all students to collectively grasp material, rather than individually. We make it clear to students that not everyone learns at the same rate, and that that’s perfectly ok. When building labs, think about the students who have programming experience already or that grasp the content intuitively – how can we stretch our labs to challenge them? During a class on writing code to make tests pass, for example, we had advanced students write their own rspec tests and learn about the process of Test Driven Development.
I can’t stress this enough. Any veteran teacher will tell you that the first two minutes can make or break an entire lesson. Find a way to hook students— issue a challenge or catch them off guard with an unexpected question (“what the heck does an array have to do with a sandwich?”). Play a video clip that may be nonsensical at first and leads to slight confusion. The idea is to intrigue the students, like a good storyteller, so they have to work a little for the payoff of what the lesson is about. It’s that much more satisfying for students when they see how the material you’ve presented in lecture connects to your hook—that’s where the ‘aha’ moments happen.
Are you a high school coding instructor? What rules do you work by? We’d love to hear your thoughts.