Let’s start by examining the biggest mistakes I was making in trying to integrate coding into my lessons for the LONGEST time.
The first time I had my students complete the Playful Polygons lesson in our geometry classes would have sounded something like this if recorded, “Ok you guys today we are going to program regular polygons! To start, drag out the green flag. Now what we want first is to put your pen down by adding this block. Next, pull out the move block and fill in the space with 100 pixels to make the first side. So we’re going to first make a square, which has a 90 degree corner, so pull out the turn counter-clockwise block and put 90 in.” Etc, Etc, Etc
We’ve really found two main things wrong with this approach. The first is that we rob kids of the freedom to think critically and openly just like we often do in lecturing. What most students are doing in this scenario is mimicking, and when you remove that crutch they will feel like they themselves don’t have the ability to work independently from you as the teacher. This phenomenon is something we like to call “learned helplessness”.
The second issue is that because they haven’t thought through how to approach the problem themselves, they don’t actually understand how the code works. So always remember that just having the code written and operating correctly doesn’t mean the kids understand anything if they’ve just copied you. So when in doubt, remember that what we want kids to do is THINK critically as problem solvers! In our written lessons we tried to give them a manageable on ramps, and high ceilings to extend, but feel free to give us feedback if we’ve fallen short on a lesson.
On the opposite side of the spectrum, I’ve made the error of just letting them go. This is especially detrimental when students are still learning the interface and functionality of the coding platform. In a program like Scratch, students need time to understand basic logistical things such as how the code blocks link and where and in what order they execute. Below is a recollection from the second coding project I implemented in a class of sophomores at a school I was new to:
“Today we’re going to do a cool coding project! You know all that factoring you’ve been doing, well we’re going to reverse engineer it with a program that will be able to factor for you using the quadratic formula.” At this point the kids were stoked. I mean they were pretty sick of factoring and using “x-factor-like” tactics, and I thought this project was going to be amazing. Well, it was more like one of those Youtube videos of a skateboarder trying to grind a staircase railing only to scorpion onto their face… Within 20 minutes kids around the room were grumbling phrases like, “This program is stupid, I can’t even get these blocks to go together.” “I have no clue what I’m doing.” “I hate programming. Why are we even doing this in math class anyway?”
Well long story short, this lesson was good. I had just dropped the ball in setting up any familiarity with the program, so kids were having issues with how the platform worked. That’s why the activities we have linked on using Hyperdocs and students as experts are so critical in setting up a coding culture. Those same students later told me how much they loved and appreciated the programming activities throughout the year once they were more acclimated. In fact, I went back and revisited the lesson months later and the kids found success and sang praises!
1) Try the lesson like you’re a student first
All of our lessons have teacher guides, but we recommend going first to the student guide so you can experience the project like a student. Make note of where you struggled to do a step. You can certainly reference the teacher guide when stuck, especially if you’re short on time (although we’re sure that never happens). This will not only help you troubleshoot student issues, but empower you to feel as though you are a coder yourself.
2) Jump Ins
Once you’ve experienced the lesson from a student perspective, you’ll have an idea where the difficult pitfalls are and can come to the rescue! Remember you want productive struggle, so give hints not just straight up answers when possible. Keep their brains ticking but also provide the type of support that will keep them upright.
3) Build up Background Knowledge
If you know students have never used a certain type of block or command, show them what it does beforehand. For example, if a lesson uses variables and lists, take 5 minutes to show them how to create them and roughly what they do, but not in the exact context of the lesson so it’s not the interface that gets in the way of a winning experience.
4) Pair Programming
Like a true Minnesotan I’m going to use the analogy of paired canoeing. If you’ve ever spent time in a canoe, you’ll know that there is a seat for someone in the front and a seat to someone in the back. Although they both paddle, it’s the primary responsibility of the back seat driver to rudder his or her oar in order to steer it along the correct pathway. The person in front should be sure to have hit a carbo load the night before, because it’s their job to supply the bulk of the power.
Similarly in a pair programming scenario, there is a power supply and a pilot. Because each of our lessons have a digitally guided document with text, images, and occasional animations, one student will have it open to navigate as the “rudder” and the other will have the coding platform open and exercise the brain muscles in writing code. And remember to SWITCH ROLES about every 15-20 minutes so students get both experiences.
We hope this helps in your quest of integrating code! Let us know about your experiences both good and bad in the comments below.
,
