Parents GuideMotivationLearning Tips

When Coding Makes Kids Upset: A Parent's Playbook

Michael Murr··8 min read

Coding frustration in kids is almost always a signal, not a personality trait. When a child is consistently upset during coding sessions, the cause is one of three things: the wrong tool for their age, the wrong project for their interests, or the wrong pace for their understanding. None of these mean the child is not cut out for coding. All of them are fixable. This guide explains exactly how to read what frustration is telling you and what to do about it without forcing through.

Key Takeaways

  • Some frustration is normal and even productive in coding. Sustained frustration that does not resolve is a signal to change something.
  • The three most common causes of coding frustration in kids are the wrong tool, the wrong project, and the wrong pace.
  • Forcing a child through frustration produces a lasting negative association with coding that takes months to undo.
  • The right response is rarely "try harder" or "push through." The right response is usually to step back and identify what specifically is breaking.
  • A 2022 study by the Learning and Work Institute found students with a dedicated tutor progress at twice the rate of self-paced learners, in part because tutors catch frustration early and redirect before it compounds.

Table of Contents

Productive vs Destructive Frustration

Some frustration in coding is normal and even valuable. Coding is one of the few school-age activities where things break constantly, where logic does not match expectations, and where the child has to investigate why. Working through that productive frustration builds resilience and debugging skill. A child who is mildly frustrated for 5 minutes, tries something different, and figures it out has just experienced one of the most valuable learning moments coding offers.

The kind of frustration to worry about is different. It looks like:

  • The child is consistently upset across multiple sessions, not just within a single moment
  • The frustration is not resolved by trying something different; it escalates instead
  • The child starts associating coding itself with the bad feeling, not just the specific bug
  • They begin avoiding sessions or saying "I'm not good at this" rather than "this specific thing is hard"

That second pattern is the signal that something structural is wrong. The child is not failing to push through frustration. The frustration is too big for what the child currently has. The right response is to change what is producing the frustration, not to ask the child to handle more of it.

The Three Root Causes of Sustained Coding Frustration

After 20 years and 200+ kids, sustained frustration almost always traces back to one of three causes. Identifying which one matters because the fix is different for each.

1. Wrong tool for their age. The most common cause. A 9-year-old being introduced to Python syntax before they understand what a variable is will feel stupid, not challenged. The same child in Scratch, building a game in the first session, will feel capable and excited. The tool has to match where the child actually is, not where a curriculum or parent expectation says they should be.

2. Wrong project for their interests. A child completing exercises with no personal connection often becomes resentful within a few sessions. The frustration looks technical (this loop won't work) but is actually motivational (I don't care about this loop because I don't care about this project). The fix is to pivot the project to something the child genuinely wants to build, even if it means abandoning the previous one mid-stream.

3. Wrong pace for their understanding. Moving too fast leaves gaps that compound into walls. A child who never solidly understood loops will not understand functions that use loops. The technical frustration ("why won't this work?") is downstream of an earlier missing concept. Slowing down and reinforcing the foundations almost always resolves it.

These causes can also overlap. A child pushed into Python too early on projects they did not choose at a fast curriculum pace is experiencing all three at once, and no amount of "trying harder" will fix any of them.

For more on what each tool is best for, see our Scratch vs Python for kids guide and our signs your child is ready for coding lessons guide.

The Diagnostic: What Specifically Is Going Wrong?

Before reacting to frustration, identify what is actually causing it. The wrong response makes the right thing harder later. Try answering these questions about your child's recent sessions:

Is the frustration recent or persistent? A child who has been engaged for months and is suddenly upset is responding to something specific (a new concept, a frustrating bug, a hard project). A child who has been mildly resistant for weeks is signalling something deeper.

Is it project-specific or general? A child who is fine until they hit one specific topic (typing, recursion, error messages) is signalling a tool or pace issue. A child who is generally unhappy with coding regardless of topic is signalling a tool or interest issue.

What does the child say when calm? Right after a session, the child is too emotional to give you good information. The next morning, in a relaxed moment, ask: "what was the worst part of yesterday's session?" Their answer is usually more accurate than what they said during the session itself.

Does the frustration look like "I can't" or "this is dumb"? "I can't" usually points at a pace or tool problem. "This is dumb" usually points at an interest problem. Different fixes apply.

For frustrations connected to losing motivation generally, see our how to keep kids motivated to learn coding guide.

The In-the-Moment Playbook

When a child is upset during a coding session, the first 60 seconds set the tone for what comes next. Here is the sequence I have found works best.

Pause without comment. Do not say "let me see what you did" or "okay, calm down." Let the child have a few seconds without anyone jumping in. Even sitting in silence acknowledges that what just happened was hard.

Ask one specific question. "What were you trying to do?" works better than "what's wrong?". The first focuses the child on the goal. The second focuses them on the failure.

Listen to the answer fully. Do not interrupt to suggest fixes. Often, articulating the goal is enough for the child to see what they need to try next. They will say "wait, hold on" and start fixing it themselves. That is the ideal outcome.

If they are still stuck, narrow the question. "Show me where you think it might be going wrong." This shifts the framing from "I failed" to "let's investigate." Investigation is a skill. Failure is an emotional state.

As a last resort, walk through the logic together. Read each line aloud and ask the child what it does. Errors usually reveal themselves the moment the child tries to explain a line they do not actually understand.

End with a small win, even if the original problem is not solved. "Let's get one small thing working before we stop" is one of the most useful sentences in coding tutoring. The child leaves with momentum, not with the bad feeling. The original bug can wait for next session.

The After-the-Session Conversation

The hardest sessions need a follow-up conversation, not in the heat of the moment but later, when the child is calm and the frustration has faded.

This conversation has three goals:

Validate the difficulty. "That was hard yesterday." Acknowledging that something was genuinely difficult, without rushing to "but you'll get it next time," matters. Children read past dismissive optimism easily.

Find out what they think happened. "Why do you think it didn't work?" Their answer reveals whether they understand what was actually wrong. If they say "I'm just bad at coding," they have generalised a specific failure into a global identity, which is a problem worth addressing directly.

Reframe the failure as data. "So it sounds like the loop wasn't doing what you expected. That's a really useful thing to notice, even though it felt bad in the moment." This is not toxic positivity. It is teaching the child to extract information from frustrating moments rather than just feel bad about them.

A child who learns to do this once or twice will start doing it on their own within a few months. That habit, treating bugs as information rather than personal failures, is one of the most valuable things coding tutoring can teach. It transfers far beyond coding.

A parent named Endi Koinok summarised what this kind of structure feels like from a child's perspective after her daughter completed a series of structured Scratch challenges: "Great program. I started from zero and learned a lot. The challenges help you figure things out yourself. Highly recommend." The "figure things out yourself" part is exactly the framing that prevents frustration from turning into avoidance. Help is available, but the work is the child's.

When to Pivot the Whole Approach

Sometimes the playbook above is not enough because the underlying setup is wrong. If, after honest diagnosis and a few weeks of trying smaller adjustments, your child is still consistently upset during sessions, consider these structural changes:

Switch the tool. If your child is in Python and struggling, dropping back to Scratch for 6 to 12 weeks often resolves what looked like a coding problem but was actually a foundation problem. Returning to Python afterwards usually feels significantly easier.

Switch the format. A child in a group class who is consistently upset may simply be in the wrong format. The pace and individual attention available in 1-on-1 tutoring resolve frustration patterns that group instruction cannot. See our is 1-on-1 coding tutoring worth it guide for the evidence.

Switch the projects entirely. If your child has been completing assigned projects without engagement, give them a session or two to build whatever they want with no agenda. Often the motivation reappears when ownership returns.

Pause for a while. Sometimes a 4 to 6 week break is the right answer, especially if the bad association has built up over months. Returning fresh with a different starting point produces dramatically different results than pushing through.

The most important thing to avoid is forcing through. A child who has been forced to do coding sessions they hated for 6 months will sometimes give up entirely, and the recovery time from that is significantly longer than the time saved by not pausing earlier.

What "Not a Coding Kid" Usually Actually Means

Children sometimes label themselves "not a coding kid" or "not really a science person." Sometimes adults reinforce this label, even unintentionally. In my experience teaching 200+ children, this label is almost always wrong, and the right context simply has not been found yet.

A specific case I think about often: a parent enrolled her daughter reluctantly. The daughter had been told by a teacher she "wasn't really a science person." She was 10, loved art, and wasn't sure why she was there.

By week 3 she was building an animated story in Scratch. By month 2 she was asking if she could make a game instead. By the end of the year she told her mum: "I think I might want to do this when I'm older."

The "not a coding kid" label was never accurate. She was a kid whose strengths were creative and visual. Scratch let her express those strengths through coding rather than fight them. The frustration she felt at the start was the natural response of being told to do something abstract and disconnected from anything she cared about. Once the connection was made, the frustration evaporated.

If your child has been labelled (by themselves, by you, by a teacher) as "not a coding kid," the most useful thing you can do is treat that label as a hypothesis to test, not a fact to accept. The right tool, the right project, and the right person teaching can change what looks like a fixed limitation into a strength your child did not know they had.

For more on getting any child engaged with coding, see our how to get your child interested in coding guide.

FAQ

My child cries during coding sessions. What should I do?

Stop the session, do not push through. The session has reached a point where no useful learning is happening. Acknowledge that something was hard. Take a break for at least a day. Then have a calm conversation later about what specifically went wrong. If this happens repeatedly across sessions, something structural is wrong (wrong tool, wrong project, or wrong pace). Forcing through will produce a lasting negative association with coding.

Is it normal for kids to get frustrated during coding?

Some frustration is normal and even valuable. Coding involves bugs, errors, and unexpected behaviour, all of which can be momentarily frustrating. The pattern to watch for is sustained frustration that does not resolve, frustration that generalises into "I'm bad at coding," or frustration that makes the child avoid sessions. These signal something structural is wrong, not that the child is failing to push through.

How do I know if my child's tutor is causing the frustration?

A few signals: the child is markedly more frustrated with this tutor than with similar activities elsewhere; the frustration started after a specific change in the tutor's approach; or the child can describe specific things the tutor does that bother them. A good tutor catches frustration early and adjusts. If your child is consistently upset across multiple sessions and the tutor is unable to adjust, the fit may be wrong.

Should I sit with my child during coding sessions?

Sometimes yes, especially in the early weeks if the format is new. Your presence helps the child feel supported and gives you visibility into what is actually happening. Over time, most children develop more independence with the tutor or self-directed work, and your sitting in becomes less necessary. If your child seems significantly more comfortable when you sit in than when you leave, that is information worth paying attention to.

What if my child says "coding is boring" instead of "coding is hard"?

This usually means the projects, not the difficulty, are wrong. A child building something they care about does not call coding boring even when it is hard. A child completing exercises they did not choose calls almost anything boring. The fix is to pivot the projects to something the child genuinely wants to build, which usually re-engages them within a session or two.

How long should I give a coding programme before deciding it's not working?

Six to eight sessions is a reasonable evaluation window. Some initial discomfort is normal as the child adjusts to a new format and tutor. By session 8, you should be seeing clear engagement, visible progress on something the child cares about, and an emotional pattern that is mostly positive. If sessions are consistently frustrating across 8 sessions and an honest conversation with the tutor has not changed anything, it is time to either change the tutor or change the format.

Want a tutor's read on what's specifically causing your child's coding frustration? Book a free Discovery Call, 20 minutes, no obligation, and you'll leave with a clear, honest plan for what to change.

Enjoyed this article?

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

Book a Free Discovery Call