nomuraya — The Curious Operator

Hands-on accounts of building, breaking, and rebuilding AI agents.

Someone who doesn't know how to program - the "wall" is in front of the screen

2026-06-17

Someone who doesn't know how to program -- the "wall" is in front of the screen

The difference between "people who get stuck" and "people who don't get stuck" in programming learning is not the English ability, mathematical ability, or even talent that is often mentioned.The difference lies in the habit of breaking down thoughts.The same structure can explain why even an easy tool like Scratch fails.

To conclude, the real barrier to programming is not the grammar of the code or the development environment, but whether you can break down what you want to do into sequential steps that your computer can perform.

“Stuck in place” is misunderstood

The words of those who have been frustrated are surprisingly similar."I stumbled on the construction of the environment", "I had to read an English book", "I did not understand the meaning of what the teacher was saying" - these stories do exist, but these are only superficial phenomena.The real wall is deeper, and it takes the form of "I don't know what I'm stuck in, but my hands just stop".

Many introductory programming books at bookstores present a procedure that says, "You can play this game by arranging blocks like this."If you imitate the procedure, it will work.However, while imitating, there is no essential training in the learner's mind.I just look at the finished product and trace the steps.As a result, you can make the games listed in the book, but you can't write a single line when it comes to the game you want to make.This is not limited to Scratch, but occurs with the same structure in Python and JavaScript.Because the teacher is teaching "how to write code" and not "how to decompose thoughts".

The trap of "I get it"

There is another problem with the introduction to programming.This is the point where the completed experience traces the steps to create the feeling of "I did it".

The feeling of being able to do it motivates me to continue learning.However, "I imitated the procedure" and "I understood how it works" are completely different.The difference is immediately apparent in the next task.If you go on without knowing "why this happens", the application will not be effective.The moment you step outside the introductory book, your hand stops.

This is not a student problem, but a teaching method problem that confuses "reproduction of procedures" and "mastery of thinking".

Three trends common to clogged people

Observing someone stuck in programming reveals three things in common.

The first is that you don't realize the distance between what you want to do and what your computer can do.I move my hand with the intention of "I want to make it move like a good button", and I can't write anything.Since the computer does not know "good feeling", it is necessary for the writer to undertake all the work of converting the intention into a structure, but that is the blind spot.

The second is that when an error occurs, it is impossible to track "which stage of my thinking broke down".In programming learning, errors are not enemies, but maps that tell us where the holes were in our thoughts.But many beginners stop thinking the moment an error occurs and close the book without reading the map.

The first is to try to imagine the completed form at once.If you can decompose "make the movement first and determine the next hit", you can move forward, but the moment you want to "move all at once", your hand stops.These three are not English skills, mathematical skills, or talents, but habits that break down thoughts.

With AI, it's still the same

I will add.Even with the popularity of AI, this structure has not changed.

The idea that "ChatGPT should write code" is correct in the short term.But the moment you try to “fix it as you intended” your AI-written code, you hit the same wall.If you can't translate what you want to do into structure, your instructions to the AI will be vague, and you won't know why the generated code doesn't match your intentions.

In the absence of the habit of decomposing thoughts, AI writes code, but it cannot move as it intends.

Called Computational Thinking

This "habit of breaking down thought" has an academic name.Computational Thinking was proposed by Jeannette Wing in Communications of the ACM in 2006.What Wing emphasized was that "this is not for computer professionals, it is a basic way of thinking that everyone should learn, just like reading and writing."

It is usually described in four columns.

Disassemble - Cut into small pieces what you want to do.Instead of "Make a game", divide it into "Move the character first, then detect the collision with the wall, and finally display the score".

Abstraction - Dropping non-essential elements to extract the gist.This corresponds to the judgment that "the color of the character will be decided later, and now I only think about the mechanism of movement".

Pattern recognition - see through similar structures.This is the realization that "this hit judgment and the process I created earlier can be written using the same mechanism".

Algorithm Design —— Assemble the procedure.It is a task that can finally be handed over to a computer.

These are the techniques of organizing the thoughts that humans have been doing on a daily basis since before computers existed, and the version that has sharpened it to the granularity that can be conveyed to computers is called programming.Therefore, the word "learning to program" is inherently close to "lifting the method of organizing thoughts to the granularity conveyed to the computer."

Mitchel Resnick of mit Media Lab, who developed Scratch, has also consistently taken the position that "Scratch is not for children to become programmers, but for children to express their thoughts."The idea is that teaching how to write code is not an end in itself, but rather a by-product.

Example: Inexperienced Programmer Completes a Case in 2 Hours

Abstract theory alone is difficult to convey, so give a familiar example.

A person with no programming experience borrowed an introductory book on Scratch from the library.I can read and write English, but I have never written a single line of code.Two hours later, the man had completed a game.It's a simple game where a child's portrait moves.

When the person who watched the completed game started playing with interest, a loophole was found.I realize that "you can clear it by poking this way", and I'll try to do it accordingly.Then, I saw the behavior and rearranged the blocks so that I couldn't use my hands.

What's important here is that you didn't write a single line of code, that you didn't read the English manual, that you didn't touch the error logs or the debugger - and yet the game is complete.There were only Japanese blocks and thoughts about the rules of the game.

What the person was unconsciously doing was exactly the above-mentioned "decomposition".Determine the movement first, consider the judgment next, and put the conditions for winning and losing at the end.Even when a loophole is pierced, observe its behavior calmly and add blocks to fill in the unexpected.

This is a routine thought process for anyone who can write a recipe for a dish, keep a household account, or teach a child something in turn.The only thing missing was the practice of describing the procedure in the form of a Scratch block, so it took only two hours.

Conversely, if a person who does not have the habit of decomposing thoughts reads the same book, they will probably not complete anything in two hours.It is not the book that is bad, but whether the learner has the ability that the book assumes will completely change the result.

Why do the same patterns occur in adult learners?

To add to that, the two-hour case doesn't show that “programming is easy.”

"If you have the habit of breaking down everyday thoughts, the cost of acquiring tools will drop dramatically."Conversely, if you try to master the tool without that habit, you will be stuck learning the operation of the tool itself.

The same thing happens at the training site.Even if a business person with a lot of work experience opens an introductory book saying "I want to learn programming", there are some people who are stuck.If you look at the proposal and requirement definition that the person is writing at work, it is often logically organized.Still, the reason is that the granularity of "business document logic" and "logic conveyed to the computer" are different.Computers don't interpret "good".

Implication on the Teaching/Learning Side

From the arrangement so far, two practical guidelines can be guided.

For those in a teaching position, the point to look at is not “whether or not you can write code.”Can learners verbally describe what they want to do, explain it in stages, or describe in their own words the condition that “if this happens, it will work”?If these are done, the tool will catch up even later.If it is not done, no matter how easy the introductory book is to understand, your hands will stop.

From a learning standpoint, when you stop and sort out what you don't know when you get stuck in programming, you can see a breakthrough.In many cases, what you don't know is not the "grammar of the code", but "the content of what you want to do".Before re-reading the code book, it is often faster to write it out on paper and check the order.

Changing the face of error

There is another thing I would like to tell the learners.

Stop reading error messages as “failure notifications.”The error is to point out that "thoughts are not intertwined here".Look at where the error occurred and ask again, “What did I expect here?”When you learn the habit, every time an error occurs, it changes to "I know where I am not chewing" instead of "I failed again".

This is not a programming-specific skill.When you notice "too much salt" in a dish, it is the same thought movement as adjusting "when and how much" from the next time.

Why “programming education” didn't solve this problem

Finally, let's touch on the structural issues.

Many programming education is designed to teach "how to use tools".How to use Scratch, Python grammar, VSCode manipulation.We do need these.However, the "decomposition habit of thinking" is not included in the use of the tool.

The reason for this is that it is difficult to teach the decomposition habit of thinking.How to use the tool is taught as a procedure.The habit of thinking can only be acquired through repeated experiences.Designing an experience takes longer than communicating the process and is difficult to measure.

Therefore, educational design that measures "now that you can write code" as an outcome becomes mainstream.Apart from being able to write code and learning the habit of decomposing thoughts, the easier to measure is the evaluation index.

It is difficult to change this structure.However, if the learners know this structure, they can consciously choose what they are trying to learn.While mastering the operation of the tool, it is ultimately the shortest distance to continue to ask "Can I break down what I want to do?"

Wrap-up

The real barrier to programming learning is not inside the screen.The wall is on the side of the person sitting in front of the screen thinking."Disassemble and sequence" - Whether or not this thought process is worn outside the context of programming separates the "clogged person" from the "unclogged person".

Whether you make the tool easier or add an introductory book, there will be no fewer setbacks if you don't intervene here.Conversely, if you have this kind of thinking, Scratch or Python can create one thing in two hours.

Even in the era when AI writes code, the thought of "converting what I want to do into a structure" does not disappear.Rather, the ability to design instructions to AI is more important than ever.

References

- Jeannette Wing, "Computational Thinking" (Communications of the ACM, Vol. 49, No. 3, March 2006) - Mitchel Resnick, "Lifelong Kindergarten: Cultivating Creativity through Projects, Passion, Peers, and Play" (mit Press, 2017)

---

*Machine-translated (MyMemory API) from a Japanese original at [nomuraya-hub.pages.dev](https://nomuraya-hub.pages.dev/). Pre-review draft. I am the same author writing under different pen names — "nomuraya / shimajima / 中翔" — depending on the medium.*

Subscribe

If you want occasional long-form posts about AI agents, FIRE, and how a curious operator thinks about both, drop your email below.

Subscribe via Substack →