Greenfoot: Teaching Java to 5th Graders

Once upon a time, I would have said that its impossible to teach 5th graders to program in Java. Even the most basic hello world requires exposure to complex concepts: the print statement must be wrapped by a method with very specific modifiers and parameters, which is then wrapped in an class and compiled. Enter Greenfoot.

When helping to teach a class for the Northwestern CTD weekend program**, I was introduced to Greenfoot for teaching and learning Java. After my first day of class, I was so inspired by the educational possibilities of Greenfoot that I wrote a little Breakout clone to show the kids the next day what they could do with Greenfoot.

Rather than using the classic programming education sequence, from hello world to user input, string manipulation, file I/O, and so on, Greenfoot instructors typically start by letting the students play games in Greenfoot. Once the students understand the mechanics of the game, we step back to cover some of the theoretical bits of programming: data types, methods, objects vs classes, and so on. Then we go through the code of the game they played to see how the theory comes together to make the game work. And finally, we help the students to change the games to behave as they wish. Its gamification of education at its core.

Structuring the class in this way results in a very different environment. Instead of having to force-feed material to students, they’re actively engaged. The primary driver of students’ learning is now their intrinsic curiosity and creativity, rather than the fear of tests hovering overhead. Its a way to escape education’s death valley (at least for programming classes).

Now, don’t take this the wrong way. I still have a lot to learn about teaching Java, particularly to young learners. Covering the theoretical material is still particularly painful, but I believe its because we don’t know the best way to help students learn it yet. I’m confident that we can find the right techniques though. For example, I particularly enjoy trying to teach objects vs classes by drawing on the students’ own experience and intuition.

One thing that I’ve noticed, though, is that teachers aren’t properly trained for this kind of environment. The students come in with different backgrounds and exposure to programming, learn at different rates, and driven by their own creativity all want to make their games do something different. This makes for a hectic and sometimes challenging environment in which to operate.

In such a student-driven learning environment, its backwards to attempt to maintain the same “command and control” style of education to which teachers are accustomed. Although I’ve written about teachers transitioning from lecturers to facilitators before, I don’t really know the best way to implement it. But I know that its not telling the students to stop exploring, to be scared of editing code/changing anything (in the case of teaching programming), and to sit and listen. In my experience, the excitement of tinkering leads to student inquiry which leads to teacher assistance which leads to more exploring. What a lovely cycle! Now, the question remains, with a student:teacher ratio fixed by budgetary limitations, how can we actually accomplish this? If I ever figure it out, I’ll let you know.

** For those of you who don’t know, I’ve taught off-and-on through Northwestern’s Center for Talent Development since I moved to Chicago. My first job in the Chicagoland area was as a Residential Teaching Assistant for the Summer Program and since then I’ve helped through the Accelerated Weekend Experience (AWE) program.