From block coding to text coding

Block editors such as Scratch and Microsoft MakeCode have made it possible for very young students to program robots. Drag a "forward" block, snap a "repeat" around it, and the robot moves. Sooner or later, though, students (or their teachers) start asking when they should move on to "real" code. This note looks at when that makes sense and how to make the jump without losing anyone.

Blocks are real code

It is worth saying first: block coding is not a toy. Scratch, created at the MIT Media Lab, and MakeCode both teach the same core ideas as any text language: sequence, loops, conditions, variables, events and functions. What blocks remove is the typing, the spelling and the punctuation, which are exactly the things that frustrate beginners and hide the logic.

For a Year 5 student working out how to make a robot stop at a wall, removing those obstacles is a feature, not a weakness.

Signs a student is ready for text

• Their block programs are getting long enough that scrolling and finding things is slow.
• They are copying and pasting the same group of blocks and want a neater way to reuse it.
• They ask how to do something the block palette doesn't offer.
• They are comfortable typing and are curious about what the blocks "really" look like.

Age is a weaker signal than these. Some Year 6 students are ready; some Year 10 students are better served by a few more months of blocks.

Use editors that show both

The easiest bridge is an editor that can switch between blocks and text for the same program. MakeCode for the micro:bit lets students build with blocks and then flip to a Python or JavaScript view of the same program. The micro:bit also has its own Python editor for when students are ready to work in text full time.

A gentle switching plan

1. Read before writing. Show students the text view of a block program they already understand, and ask them to find each block in the text.
2. Change one value in text. Edit a number or a message in the text view and switch back to see the block update.
3. Type one small program from scratch that they have already built in blocks.
4. Introduce errors on purpose. Remove a colon or break the indentation and read the error together. Error messages stop being scary once students have caused a few deliberately.
5. Only then start new projects in text. Keep blocks available for quick experiments.

What changes for robots

Text code makes some robot tasks much easier. Functions keep long programs tidy: a turn_left(degrees) function can be written once and reused everywhere. Lists make sensor arrays manageable. And text code is easier to share, compare and copy into a team notebook.

It also brings new ways to fail. Typos in variable names, wrong indentation and missing brackets will all stop a robot cold. Encourage students to make small changes and test often, exactly as they did with blocks.

Python or C++?

For most schools, Python is the natural next step after blocks. It reads close to plain English, it is used widely in industry and science, and it is supported on the micro:bit and several other school boards. Arduino boards are usually programmed in a version of C++, which is stricter and wordier but teaches students a great deal about how hardware works. Many students meet Python first and C++ later, and that order works well.

Whatever the language, the habits matter more than the syntax: plan, write a little, test, read the error, fix, repeat.

Supporting a mixed class

In most classes some students will be racing ahead in Python while others are still happiest with blocks. That is fine, and it doesn't need two separate lessons. Set the same robot challenge for everyone and let students choose the editor. Pair a confident text coder with a block coder now and then, and ask the text coder to explain each line in plain words. Explaining code is one of the fastest ways to understand it, and the block coder gets a gentle preview of what's coming.

It also helps to keep a class "translation wall": a poster with common blocks down one side and their text equivalents down the other. Loops, if/else, variables and functions cover most of what a school robot needs. Students add to the wall as they discover new pairs, and it becomes a reference they actually use.

Assessing the switch fairly

When marking work, focus on the thinking rather than the language. A clear block program that solves the problem well shows more understanding than a messy text program copied from the internet. Ask students to describe what their program does, predict what will happen if a value changes, and explain how they found and fixed a bug. Those answers reveal understanding in either format.

Sources: MakeCode Python for micro:bit; Scratch ideas; Python Software Foundation.