The syntax is the easy part

Open any beginner programming course and count how much of it is vocabulary. Where the braces go. What a semicolon terminates. The difference between == and ===. Whether the loop counter starts at zero.

All of that is real. None of it is the hard part.

The IDE already knows the words. It will autocomplete your method names, catch your unbalanced parenthesis before you finish typing it, and tell you that you passed a string where an integer was expected. Every year it gets better at the vocabulary, and every year the vocabulary matters slightly less.

What it cannot do is tell you that you solved the wrong problem.

The thing that doesn't get taught

Here is the shape of the actual skill: before you write anything, you hold the whole situation in your head at once. Not the code. The situation. What comes in, what has to be true, what happens when it isn't, who is waiting on the answer, and what it costs to be wrong in each direction.

People who do this well look fast. They are not fast. They spent the time up front, where it does not show, and then the writing part went quickly because by then it was transcription.

People who were never handed this concept look slow and unlucky. They write something, run it, get a wrong answer, change something, run it again. Try after try, still wrong, because the picture was never complete. It reads like a talent problem. It is a teaching failure.

Why I keep saying it this way

If the hard part were memorizing syntax, then the best programmers would be the ones with the best memory, and tooling would have flattened the field years ago. Neither of those turned out to be true.

The hard part is seeing the whole thing before you commit to any of it. That is learnable, it is teachable, and almost nobody teaches it, because it does not look like curriculum. It looks like experience.

This notebook is my attempt to teach it on purpose.