The first time I introduced coding to a class, as part of a games design project with Kodu (a visual programming language for children), things did not go exactly as planned.
My first mistake was underestimating just how long the students would want to spend trying out all the landscape-design tools that Kodu has to offer. I either had to abruptly end their exploration - despite it clearly leading to some interesting discoveries - or delay the content I wished to cover.
Then, as the project progressed, a number of students installed Kodu at home and learned how to do more than I’d imagined they would - some of them through experimentation and some by following the video tutorials that I’d told them about.
Obviously, I was over the moon that they were so into it, but it did make timings a little tricky. It meant that students were getting to grips with the tools at different rates.
The role of play in learning about computing is important because you can’t show students every single thing a program can do. But the above experience made me wonder how we might introduce new software to pupils in a way that gives them the freedom to explore, but with some structure to it.
Stuart Ball, Microsoft UK Partners in Learning programme manager, shared an idea with me that seems a good solution. He suggested that when you introduce your class to a new program, you should tell them that they are going to spend a couple of lessons creating a user guide to help other people get to grips with it.
To begin with, create two working walls (or use two large sheets of paper) and get a stack of Post-it notes for students to write on.
On one working wall, students should stick Post-its detailing problems that they have solved or things they have found out.
On the other working wall, they should add Post-its with problems they’ve stumbled across that they haven’t been able to solve.
Students can then move between the two walls, learning each other’s top tips and trying to solve each other’s problems. At the end of it all, the notes can be gathered together and put into a booklet.
Of course, you could go a bit more digital and get them to share their “problems solved” and “problems discovered” using collaborative tools such as Lino (en.linoit.com), a wiki, Google Docs or similar.
However you choose to do it, the idea remains the same: get students to think carefully about the problems they’re finding and solving as they explore a new tool. This will help them to use their time as effectively as possible.
