In computing education, we often talk about progression as if it’s a neat, linear path. Pupils start with ScratchJr, move on to Scratch, and then, somewhere between eleven and fourteen, we ask them to leave behind those bright, friendly blocks and begin writing code in text. By GCSE, they’re wrestling with OCR Exam Reference Language, and by A level, they’re coding in Python or Java. On paper, it looks tidy. In practice, it’s messy, difficult, and revealing.

This moment — the shift from block-based to text-based programming — is more than a change of tool. It’s a change in how learners think. It’s the point where many decide whether computing is for them or not. And it’s a point that we, as educators, need to understand far better.

Block-based languages like Scratch are remarkable. They make the invisible visible. Pupils can see the structure of their programs, the flow of control, and the relationships between events, loops, and variables. The blocks themselves embody logic. When they click together, they make sense; when they don’t, the computer tells you so. It’s playful, forgiving, and immediate. Children can experiment without fear of breaking anything. They learn through exploration and creativity.

But text-based languages are different. Suddenly, there’s nothing to see. The structure that was once obvious now exists only in the mind. Instead of colourful shapes, there are words, brackets, commas, and colons. The computer becomes less forgiving. One missing space or mistyped keyword can halt everything. It’s no longer obvious what went wrong or why. For learners, that can feel like falling off a cliff.

Teachers face a real dilemma. Should they move to text early to prepare pupils for exams, accepting that it might crush some of the joy? Or should they stay with blocks longer, even if it means pupils are less prepared for the formal demands of GCSE or A level? It’s not an easy decision, because both choices carry risks.

The problem isn’t just timing. It’s about what we think programming is. Too often, we treat text-based code as the “real” thing and blocks as just a toy version. But that misses the point. Scratch is programming. It teaches computational thinking — sequencing, iteration, selection, decomposition, abstraction. It builds the habits that matter most. What changes with text isn’t the logic; it’s the language.

In many ways, this is like learning to write in a second language. You already know what you want to say, but now you have to express it through unfamiliar symbols and rules. Syntax becomes the gatekeeper. Those who already feel confident, or who have strong literacy skills, make the leap more easily. Others, particularly those who have struggled with reading or spelling, can feel excluded. The barrier isn’t their understanding of computing; it’s their relationship with text itself.

That’s why the transition from blocks to text isn’t just a technical issue — it’s also social, emotional, and educational. It’s about identity. Pupils who once saw themselves as successful coders can suddenly feel lost. They start saying things like “I’m bad at coding,” when what they really mean is “I’m bad at remembering punctuation.” The danger is that we mistake those feelings for lack of ability.

So what can we do? Part of the answer lies in using environments that bridge the two worlds. Tools like Snap! or Microsoft’s MakeCode allow learners to toggle between blocks and text, or see how one translates into the other. This helps them understand that the ideas remain the same, even if the notation changes. It turns the transition from a leap into a series of small, comprehensible steps.

But tools alone won’t fix it. We need to change how we talk about programming. If we describe it as a test of accuracy — a world of colons, brackets, and strict grammar — we make it sound joyless. If we describe it as a language of ideas — a way of building, exploring, and expressing — we keep it open and human. When pupils see programming as creative, they stay motivated. When they see it as rule-following, many switch off.

Good teaching makes the difference. We need to give pupils time to debug, to reflect, to play. We should celebrate problem-solving, not just perfect syntax. We should also be explicit about what’s really changing when they move to text. It’s not their intelligence or their capability; it’s just the representation. The thinking underneath is the same.

This matters because computing education isn’t just about producing programmers. It’s about developing computational thinkers — people who can reason logically, design systems, and understand how technology shapes their world. If we make the journey from blocks to text too abrupt, we risk losing learners who might have gone on to be creative, capable technologists.

The shift to text should feel like a bridge, not a cliff edge. And building that bridge requires thoughtful teaching, patient scaffolding, and an understanding that code is more than syntax. It’s a way of thinking and creating. When we get that right, pupils don’t just survive the transition — they grow through it.

We often say that computing is about precision, but it’s also about imagination. The goal isn’t to replace colourful blocks with monochrome text, but to help learners see that both are expressions of the same ideas. The blocks are a picture of code; the text is its language. Together, they tell the story of how ideas become systems, and how learners become creators.

Loosely based on my talk at the 2025 CAS Conference