ScratchLearning TipsBeginners

Teaching Kids If Statements: The Demo Mistake to Avoid

Michael Murr··8 min read

Last updated: September 2026

Teaching kids if statements goes wrong in a specific, avoidable way. The adult writes a condition that happens to be false when the program starts, runs it, and nothing appears to happen. To an adult that is a correct demonstration. To an 8-year-old, nothing happening means broken, and the next ten minutes are spent recovering from a misunderstanding nobody created on purpose.

I watched exactly this cost six minutes of a lesson last month. The fix takes one decision: your first conditional demo must produce something the child can see.

Table of Contents

What actually goes wrong

Here is the sequence, which I have now seen enough times to predict.

The tutor introduces conditionals with something like "if the character's position is greater than 100, do this." It is a reasonable example. The problem is that at the moment the program starts, the character is usually sitting near the middle of the screen, so the position is not greater than 100, so the branch does not run.

The child clicks the green flag. Nothing visible occurs.

Everything after that point is repair work. In the lesson I reviewed, the child then confused the value being tested with the character's size, guessing that a bigger number meant a bigger sprite. Then, asked to find where 100 was on the screen, he counted the visible grid squares and said "that's not 100, that's one, two, three, four, five."

Both of those are completely reasonable inferences from what he could see. He had been shown a number with no reference for what it measured, attached to a block that appeared to do nothing.

It only clicked when the coordinate grid finally went on screen, about six minutes in. That grid should have been the first thing shown, not the last.

The two concepts hiding inside one block

This is the part that gets missed, and it explains why a child can look brilliant at conditionals one week and lost the next.

In the same set of lessons, the child had earlier understood if else with a sensing block extremely well. Asked to explain his own code, he said this, unprompted:

His words were that hello and moving were under the else, so whenever he clicked the space, anything under the if would happen. They were both in different places. Press the key and it says hello; do not click it and it just listens to the else.

That is an 8-year-old explaining mutually exclusive branching, correctly, in his own words. A week later he could not follow if position > 100.

That is not a regression. They are different concepts wearing the same block.

Teaching if else with a sensing block asks a child to grasp one idea: two paths exist and only one of them runs. Teaching if with a numeric comparison asks for all of that, plus what the number actually measures, plus what greater-than means in this context, plus the idea that a sprite's position is a value you can read at any moment. One is moderate. The other is much harder, and it arrives disguised as the same lesson.

A sensing block like "key space pressed" is self-explaining. The child presses the key or does not, and the answer is obviously yes or no. A numeric comparison asks them to hold three new ideas at once, and if any one of the three is shaky the whole thing collapses.

Teach branching first. Teach comparison later, as its own topic, with a gap in between. Bundling them is the actual mistake, and the failed demo is just where it becomes visible.

Make the tested value visible first

Whatever your condition tests, put that value on screen before you write the condition.

In Scratch this is one checkbox. Tick the box next to the sprite's x position in the motion blocks and the live value appears on the stage. Drag the character around and the number changes as they watch. Now the number means something, because they have seen it move.

Then, and only then, write the condition. The child can see the value, see the threshold, and predict which way the comparison will go before you run it. Ask them to predict. That prediction is the whole lesson.

The same principle applies elsewhere. If you are testing a variable, show the variable. If you are testing a timer, show the timer. A comparison against an invisible number is a magic trick, and children do not learn from magic tricks.

I hear a version of this from parents repeatedly: what makes it stick is being made to figure things out rather than being walked through them.

Figuring it out requires having something to look at. That is the entire argument for putting the value on screen first.

A teaching order that works

This is the sequence I would use with any beginner, in Scratch or Python.

Step 1: Start with a sensing condition, not a number

Key pressed, mouse down, touching a colour. The answer is obviously yes or no, and the child can trigger it themselves. Scratch groups these under control blocks, with the sensing options sitting right alongside.

Nothing here requires understanding what a number measures, which is the whole point of starting here.

Step 2: Make both branches do something loud

Say something, change colour, move. If the else branch is empty, the child only ever sees half the mechanism, and half a mechanism is what produces the "it's broken" reaction later.

Loud also means unmistakable. A five-pixel move is not a demonstration.

Step 3: Have them predict before running

"If I press space, what happens? If I do not?" Ask both. Prediction is what turns watching into thinking, and a wrong prediction is more useful than a right one because it tells you exactly which half of the mechanism has not landed.

Step 4: Ask them to explain it back

Have them talk you through it as though they were teaching you and you had never seen it. It takes about four minutes and it is the fastest way to find out whether branching has actually landed or whether they are describing what they watched you do. How to teach your child Python at home covers this check in more detail.

Step 5: Stop there for that session

Comparison is a separate lesson. Ending here, with something working and understood, is worth more than pushing into the harder concept while attention is fading.

Step 6: When you come back to it, show the number first

Put the value on screen. Let them drag the sprite and watch it change. Only once the number means something to them should you write anything that compares against it.

Step 7: Choose a starting state where the condition is true

Your first run must do something. Then show the false case second, deliberately, and name it out loud: nothing happened, and that is the correct answer.

Step seven is the one that fixes the six lost minutes. Once a child has seen a conditional work, "nothing happened" becomes an interesting result instead of a broken program.

The worked example, block by block

Here is the whole first lesson as actual blocks, so you can build it alongside them rather than improvising.

Start a new project and drag out when green flag clicked. Under it, go to x: 0 y: 0 so every run begins somewhere known. Then forever, and inside the forever loop an if else block from Control.

Into the hexagonal slot at the top of the if, drop key space pressed? from Sensing. That hexagon shape matters and is worth pointing out: only yes-or-no blocks fit there, and Scratch physically will not let a child put a number in it. The shape is teaching the type system, which is a genuinely elegant thing about the language.

Inside the if branch, put say "Hello!". Inside the else branch, put move 5 steps and next costume.

Run it. The cat walks. Hold space and it stops walking and says hello. Release and it walks again.

That is the entire lesson, and it works because both branches do something obvious. A child can toggle between two visible states with their own finger, twenty times if they want, and the mechanism is completely exposed.

Now break it deliberately. Take the move 5 steps out of the else and put it below the whole if else block, still inside the forever loop. Ask what will change before running.

The answer is that the cat now walks all the time, including while saying hello, because that move is no longer inside either branch. It runs regardless. Children find this genuinely surprising the first time, and it teaches containment better than any explanation of scope, because they watched the behaviour change when the block moved.

Put it back, then try one more variation: swap the two branches so the cat walks when you press and stops when you do not. Same blocks, inverted meaning, and a child who can predict that outcome correctly has understood branching.

When to introduce else-if

One question you will get, usually within a lesson or two: what if I want three things instead of two?

Scratch has no else if block. You nest a second if else inside the else branch of the first, which is visually obvious once seen and almost impossible to describe in words. That nesting is worth showing early precisely because the block shapes make it self-explanatory: the second decision sits visibly inside the "otherwise" of the first.

Do not introduce it in the same session as the first conditional. It is a second concept, and it lands cleanly a week later when the first one is solid. Python does have elif, and a child who has physically nested Scratch blocks understands what elif is doing the moment they meet it, which is a good argument for teaching the nesting version first even though it is clumsier.

The same trap in Python

Everything above applies when a child moves to Python, and the visibility problem gets worse rather than better.

Scratch at least gives you a stage. You can tick a checkbox and the value sits there on screen, updating as the sprite moves. Python has nowhere to put it. The value being tested exists only inside the program, which means a child writing if score > 100: is comparing against a number they have never once seen with their own eyes.

The fix is the same fix, done manually. Print the value before you test it:

score = 0
print("score is", score)
if score > 100:
    print("You win")
else:
    print("Not yet")

That print line is not debugging clutter. It is the equivalent of the Scratch checkbox, and I leave it in until the child stops needing it. Watching score is 0 appear immediately above Not yet is what makes the else branch make sense, because now the reason is visible rather than inferred.

Two further Python-specific notes worth knowing before you teach it.

The colon and the indent do work that Scratch does with shape. In Scratch, the blocks inside an if are physically held inside the block's mouth, so containment is drawn for you. In Python that same containment is carried by a colon and four spaces, and a child who has not been told that explicitly will put lines at the wrong level and get behaviour they cannot explain.

And else is optional in Python but almost never optional when teaching. A bare if with no else recreates the exact failure this whole article is about: when the condition is false, nothing happens and there is nothing on screen to tell the child why. Write the else even when the program does not need it, at least until the mechanism has landed.

How to check it landed

Three questions, none of which require you to read code.

"When does this part run?" Point at the blocks inside the if. A child who has it will say something about the condition. A child who does not will describe what the code does without saying when.

"What would make it not run?" This is the harder one and the better test. Understanding a conditional means understanding the case where it does not fire.

"Show me the else happening." If they can deliberately trigger the other branch, they understand there are two paths, which is the concept.

If your child is at the earlier stage and you are not sure whether conditionals are the right next step, what your child actually learns in Scratch lays out where this sits in the sequence.

Frequently Asked Questions

What age can a child understand if statements? Most children handle a simple yes-or-no conditional from about 7 or 8, usually in Scratch with a sensing block. Numeric comparisons typically land a year or so later, because they require understanding what the number measures as well as the branching itself.

Why does my child think the program is broken when nothing happens? Because from where they are sitting, a program that produces no visible change is indistinguishable from a program that failed. Nobody has taught them yet that "the condition was false" is a normal, correct outcome. Show a working conditional first, then introduce the false case deliberately and name it.

The Bottom Line

Conditionals are not hard for children. The standard way of introducing them is hard, because it opens with a demonstration that produces no visible change and asks the child to compare against a number they have never seen.

Show the value first, make the first run do something, and treat branching and comparison as two separate lessons. The concept usually lands the same day.

I teach kids ages 8 to 16 online, 1-on-1, and sequencing concepts like this properly is most of what makes a lesson work. Book a free Discovery Call.

Enjoyed this article?

Your child can learn this and more with a dedicated 1-on-1 tutor.

Book a Free Discovery Call