From Concept to Implementation
"I know I need a shopping cart. I have no idea how to implement one." The loop that derives code from behaviour, the difference between implementation and engineering, and the principle: make the thing smaller until you reach something you know how to build.
"I know I need a shopping cart. I have no idea how to implement a shopping cart." The gap is not a missing library or a missing tutorial; it is that "cart" has not yet been turned into state, operations and rules. Once it has, the code is short.
I need X → what is X → what information → what can happen → what rules → what examples → how to represent → which data structure → what each operation does → pseudocode → one operation → tests from the examples → edge cases → integrate. Fourteen steps, and code is the eleventh.
"How do I make a cart add items?" is an implementation question. "Where is the cart stored, synchronised, validated, secured, scaled?" is an engineering question. Conflating them is why beginners are stuck at both.
Three questions, three levels: can I make it work (programming), can I structure it clearly (design), can it operate in a real system (engineering). The domain's three stages — Discover, Implement, Engineer — and the fuller path Discover → Model → Implement → Engineer → Operate.
If you do not know how to build the thing, make the thing smaller until you reach something you do know how to build. Cart → addItem → find the existing item → loop through the collection → compare two ids. The last one you can write; build back up from there.
Build the feature; hit a gap; take the one focused lesson; practise the primitive; return to the feature. Against the other order — learn HTML, CSS, JavaScript, React, Node, SQL, and eventually build something — which teaches everything except how to build the thing you wanted.