COMPUTER SCIENCE REVISION

For several years, I have taught KS3 Computer Science in different ways, trying to find the magic formula that will make students fall in love with coding. Students learn to code by following instructions, looking at examples, debugging their programs and solving problems. It works, to an extent. They pass exams.

But do they love it? Do they see themselves as creators of code?

This year I took a module on creative education at the University of Reading that completely changed how I think about teaching Computer Science. I expected it to focus mainly on how to make students more creative. I was wrong. Instead, it challenged how I think about creativity in my own practice.

The first lesson was simple, but uncomfortable: if we want students to be creative, teachers need to practise creativity themselves.

Our lecturer suggested something she called a “creative date”. Teachers should schedule time in their calendar – an hour dedicated entirely to being creative. There are only two rules: you cannot share that time with anyone else, and you must spend it doing something creative. You might sing, draw, play an instrument, write, or even code.

For many teachers, this sounds unrealistic. When you are exhausted, burned out or overwhelmed, booking time for creativity can feel indulgent. My first reaction was exactly that: I’m too busy for this.

But after reading the research behind it, I changed my mind. We spend so much time supporting students’ development that we often neglect our own. If we want creativity in our classrooms, we need to nurture it in ourselves first.

The second insight was that creativity does not belong only in Art lessons.

Creativity is about generating original ideas, taking risks and solving problems in new ways. That is exactly what programmers do. In fact, this was already part of my thinking during my PGCE research, and it is one of the reasons we use Minecraft Education in my school.

Minecraft’s coding editor allows students to write code, run it and immediately test what they have created. It provides enough structure to learn programming concepts while also giving students freedom to experiment. Students can design their own structures, test ideas and debug their code in a playful environment.

What matters most in this environment is not the final product but the process. When coding feels like play, students become far more resilient when facing errors and debugging challenges.

The third insight is collaboration.

Much of Computer Science education is highly individualistic: one student, one problem, one correct solution. We assess individually, grade individually and often rank students against each other.

Yet real-world software development is deeply collaborative. Developers pair-program, review each other’s code, discuss architecture as teams and build solutions together.

Because of this, I have started encouraging more pair programming in my classroom. Students present their code to others, explain their thinking and collaborate in small competitions. Instead of working in isolation, they learn from each other’s ideas.

If we want students who innovate, take risks and genuinely enjoy coding, we need to rethink how our classrooms work. Not by lowering standards, but by creating space for exploration, making failure safe and allowing time for play.

The irony is that when I introduced these changes, exam results did not drop. In fact, they stayed the same or improved.

So here is my challenge: try one small change this term. Give students space to play, fail and create something they genuinely care about.

Then see what happens.