Think about when you began to code. You tried printing 'Hello World' and that was good. Then you tried doing some more, and quickly ran into some trouble. At this crucial point, is where you are bound to learn the most. Troubleshooting is part and parcel of the experience. People need need to experience those painful points to grow, even young programmers.
I started coding by copying BASIC programs out of magazine (the olden days) and it was excruciating as a child limited by attention and focus. I never really learned anything about why things worked or didn't until much older. Slapping things together for fun and extending things to try new ideas seems way more effective to me.
Many people may give up when they encounter this trouble, but it doesn't mean they can't program eventually. Scratch may give them the tools they need to see what programming can do, then moving on from there.
Two girls was creating a program where multiple characters had a conversation. Each character paused a set amount of time before saying its next line, and because the pauses weren't timed correctly, the characters kept talking over each other.
We draw a timeline together so the students could understand what was going on. The kids realized that every time one character was adjusted, every other character's code needed updates to match, and that this would get increasingly complicated as more lines of dialogue were added.
We talked through adjustments that could be made to lower the complexity. I suggested that when one character finishes speaking, it should "broadcast" a signal that it's the next character's turn. I don't remember if they actually refactored it, but they understood the problem-space and tradeoff.
