Last year at this time, I was trying not to think about kindergarteners. I was still teaching ninth grade English and had just accepted a job teaching technology to K-5. I was excited about the challenge, and I knew that I'd bitten off more than I could chew.
Developing the tech curriculum challenged me to teach programming or at least computational thinking at each elementary grade level. Our school is mid-pivot in technology -- we're in our second year of a middle school 1:2 iPad program, our first year of having a cart of iPads available for elementary, and our last year of two PC labs for the students to use (next year we'll have only one lab). Knowing this, I wanted to design a program that mostly used tablet-based tools.
Challenges and Resources
I was really excited when I was introduced to the apps Daisy the Dinosaur and Hopscotch. Both use visual blocks to represent commands. This approach to syntax is physical, like puzzle pieces. The commands fit together if they work together and are grouped into color-coded families. These features are great for kids. Color helps them navigate, and the physical syntax guides them toward success. From a teacher perspective, it's much easier to find errors in this physical syntax. (I don't know how many missing semicolons I could find in a class period.)
With these apps, I was confident that I had a good entry point for grades 1 and 2. Working with a kindergartner during coding club, I asked her to find the block that ended with the word "up." Now, in my defense, I thought chances were pretty good that she'd know such a likely sight word. She was incredulous. "I can't read!" So here was my challenge: can I teach programming to students who do not yet read? Of course, I looked beyond this challenge to see the next: can I use programming to support and deliver literacy instruction?
I'm happy to report that, my own surprise, the first challenge has been met. There are many ways to get pre-reading students to engage in meaningful coding challenges that develop computational thinking. My short list includes Kodable, LEGO MINDSTORMS Fix the Factory, and Bee Bots. With Tynker and the planned release of Scratch Jr, it seems like there are new platforms to support young coding all the time. As a critical and reflective teacher, I know that any of these tools is only as good as the lesson it supports.
As a push-in tech teacher, I work closely with the classroom teachers to create lessons that dovetail with and support their lessons. Real-world programming with students or with robots can create great opportunities for content integration. My first graders program a robot to fly to the planets in order (see the video below). I use the content as the surface on which the robot operates. This format also creates social learning opportunities. Since it's challenging for a group of six students to work on a robot, I plan for four to a robot. So in many ways technology class is a communication workshop and a crash course in ninja-level sharing. I am grateful that my teachers stay to help me out. We often have three adults in the room with 24 kids and six robots.
Practical Tips for the Early Grades
Elements of Programming That Support Pre-Readers
- The concept of code (written language)
- Cause and effect
- Left-to-right reading
- Problem solving
How Programming Supports Social Learning
I was looking for standards about social and emotional learning, but they are not nearly so common as other standards. My school values social and emotional growth, and it's an important part of all classes, tech included. If you've never handed out devices to students, you may not know the almost universal body language of pulling the device close in and turning away from other students.
The Power of Pairs
Until my students really understand an app, I like to have them share an iPad. We always have to discuss how to talk to your partner about sharing and offering help. I really appreciate my classroom teachers' knowledge of the students at this point and ask them to pair the kids up. While it's hard to share devices like this, I see a real learning benefit. Most students will stay tuned in to what their partner is doing while waiting for their turn. As they watch, they mentally rehearse and problem solve, building their understanding for their next turn.
When we program robots, we work in groups of four students per robot. This can be challenging and a little chaotic, which is why we take the time to model and rehearse some group communication skills and sentence stems. When we give each student a specific role (programmer, input engineer, debugger, recorder), some of the students are more successful. In these roles, the programmer is in charge of writing the program. To do this, she lays out the programming command cards left to right. The input engineer presses the buttons on the robot to input the program from the cards. The debugger watches the robot execute the program to check for errors or locate any mistakes in the program.
From Pairs to Parallel Play
The first time we explore an app, we do so in pairs, but once the students seem comfortable with it, we graduate them to working individually. One delightful surprise this year was students asking if they could move their chairs together to work side-by-side even though they had their own iPads.
Keeping Learning at the Center
One challenge of programming with robots and apps is that they are designed to look like toys and games. My goal is to structure an interaction that's thoughtful enough for students to build their understanding of programming and robotics. With the robots we have, you program directly onto the robot using the buttons on the top. I ask my students to use command cards to plan out their programs. The students want to physically steer the bot around and input commands as needed. "But I can do all that in my head," they object. Without a physical record of the commands, there is no way to debug, edit, or even audit the program as it runs. In this case, the cards are the critical difference between learning and play.
To App or to Bot, That Is the Question
Whether it is nobler in the mind to work in groups or alone, to take to desks or abandon them into a sea of learning, these are the choices that wake teachers up at night. When bringing programming to young students, should you use an app or a robot? This decision might be based on what you have available to your class. In a tablet-rich environment, it makes sense to focus on apps, but if you're going to buy some tech, which will give you the most return? Here's a quick side-by-side. I like Kodable because it's another great learning resource on my iPad cart. I like the Bee Bots, as I can make some great connections to content.
|Kodable Pro||Bee Bots|
|Structured interaction||Strong content integration|
|Built-in tutorials||Stand-alone unit, no device needed|
|Graduating complexity||Limited complexity|
|Isolated from class content||Simple interface|
|Cost per unit: $6.99 per license (up to 10 units)||Cost per unit: $90.00|
The Bee Bots could be shared effectively between several classes. A good lesson with the robots requires a good deal of prep. This can mean laminating goal cards, creating command cards, building maps for the bots to navigate, and even downloading custom jackets to turn the bees into rockets when needed. You can find materials for this at Primary Treasure Chest.
If you've taught coding to early elementary grades, please tell us about it.