Tutorial Dependency
If you can only build what a tutorial builds, you have not learned the tool; you have learned the tutorial. The way out is a ladder: follow it, modify it, build something similar without it, then build from requirements alone — and the last rung is where the understanding is tested.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
You have followed a dozen tutorials and can reproduce each one, but a blank requirement leaves you stuck. How do you tell tutorial fluency from understanding, and how do you get from one to the other?
You built the store's product page by following a tutorial, then the cart from another, and both work. Now the founder asks for "customers can save a product to a wishlist". There is no tutorial for a wishlist on this stack, and you notice you are searching for one instead of building it.
Find the closest tutorial and adapt it. A wishlist is like a cart, and there was a cart tutorial; following it again with the words changed feels like building a wishlist, and it will probably produce one.
The adapted tutorial produces a wishlist with the cart's shape — quantities, a total, a checkout button — because the cart tutorial had those and the reader could not tell which parts were "cart" and which were "list of products attached to a customer".
- The adapted tutorial produces a wishlist with the cart's shape — quantities, a total, a checkout button — because the cart tutorial had those and the reader could not tell which parts were "cart" and which were "list of products attached to a customer".
- The first requirement with no nearby tutorial stalls completely: "merge a guest's wishlist into their account when they log in" has no video, and the search for one is what the afternoon becomes.
- Every tutorial followed adds fluency in following tutorials and none in reading a requirement. A dozen working projects sit in the portfolio, and the blank page is as blank as it was before the first one.
- The dependency is invisible from inside. Each tutorial felt like learning, because each one ended with something working, and nothing in the loop ever asked the reader to produce something without one.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat a tutorial as the first rung of a ladder whose top is "build from requirements alone", and refuse to count the tool as learned until the top rung has been climbed at least once. Follow the tutorial; then modify its result in a way it did not anticipate; then build something similar to it without it open; then take a requirement the tutorial never covered and build that.
- Each rung tests something the previous one did not. Following tests that you can execute instructions. Modifying tests that you can predict what a change does. Building something similar tests that you retained the shape. Building from requirements tests that you can go from a need to a design without a shape being handed to you — which is the skill the job actually requires.
- Where you get stuck on a rung, that is the exact thing the tutorial was doing for you. Name it, look it up in the documentation as a specific question, and climb again. The stuck point is the finding; it is not a reason to go back to the tutorial.
- Say precisely what "tutorials show production" would have to mean in order to be true, and notice that it is not: a tutorial shows a path that worked once on the presenter's machine, with failure paths, load, deployment and the requirements you actually have all left out. It orients; it does not represent.
The ladder, rung by rung
The rungs are ordered by what each one tests, and the order matters: a rung you have not passed makes the next one meaningless, because the next one's failures cannot be told from the previous one's. Someone who cannot modify a tutorial's result will not learn anything from failing to build without it.
The alternative order below is real, and it is how experienced engineers usually meet a new tool: they skip to the top, get stuck, and descend to a tutorial only for the specific thing that stopped them.
- 1Follow the tutorial to its working result
because It gives the vocabulary, the setup and the experience of the pieces connecting once, faster than any other source.
- 2Modify the result in a way it did not anticipate, predicting each change
because Prediction is the first test of understanding; a result you can only reproduce is not understood.
- 3Build something similar from an empty project with the tutorial closed
because Retention of the shape is tested only when the shape is not on screen; every peek is a finding.
- 4Build a requirement the tutorial never covered, from the requirement alone
because This is the skill the job requires — need to design — and nothing below this rung tests it.
The top rung, made concrete
The wishlist as a vertical slice is what the top rung produces: a requirement turned into a thin path through every layer, built without a walkthrough. What it proves and what it does not prove are both worth stating, because the slice passing is not the same as the tool being learned — it is one requirement's worth of the tool.
The stuck points found while building this slice are the syllabus for the next one.
- PageA "save" control on the product page and a wishlist page listing saved products.
- APICreate and delete a wishlist item for the current customer; list the customer's items.
- LogicResolve the current customer from the session; reject a duplicate save.
- DataWishlistItem(customer, product) with a uniqueness constraint on the pair.
How the dependency shows itself
Dependency is easier to see from its symptoms than from inside. Each row below is a moment where a tutorial-dependent engineer and an understanding one do something different, and the difference is observable by the person themselves.
The response column is always some rung of the ladder. There is no row whose response is "find a better tutorial".
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| A requirement arrives with no nearby walkthrough | The afternoon is spent searching for one | The move from requirement to design has never been practised on this stack. | Top rung: decompose the requirement — actors, actions, data, persistence — and build the slice from the docs. |
| A tutorial-built feature needs a change | The change breaks something and the reason is unclear | The result was reproduced, not predicted; the parts and their dependencies are unknown. | Second rung: modify with predictions until the breakages are expected. |
| Two tutorials disagree on how to do the same thing | Paralysis, or both patterns copied into the codebase | Neither pattern is understood well enough to be compared against the requirement. | Read the documentation for the concept both are using and decide against the store's needs (Documentation Before Tutorials). |
| Asked to explain why the feature is built this way | "That is how the tutorial did it" | The tutorial's decisions were inherited, not made. | List the decisions, make each one explicitly, and write down the ones that changed (Explain It Back). |
How to do it
Most important first.
- After finishing a tutorial, close it and change its result in a way it did not cover — add a field, remove a feature, change where the data lives. Predict what will break before you change it (Prediction Before Execution).
- Build the same thing again from an empty project without the tutorial open. Where you have to peek, write down what you peeked at; that list is what you have not learned yet (Build From Memory).
- Take a requirement the tutorial never mentioned — the wishlist — and build it using only the documentation and your own decomposition. Start from the requirement: who, what actions, what data, what must persist (I Have No Idea Where to Begin).
- When stuck, phrase the stuck point as a question about the tool — "how does this framework let me read the logged-in user in a server handler?" — and answer it from the docs, not from a new tutorial (Reading Documentation With a Goal).
- Keep a note of the decisions the tutorial made that you have now made differently. When the list is long, you have stopped depending on it.
- Use the hint ladder from the manifesto when stuck rather than a full solution: direction, then the abstraction, then pseudocode, then partial code (The Hint Ladder).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The wishlist, from requirements. Actors: customer. Actions: save a product, remove it, see the list. Data: Wishlist, WishlistItem — no quantity, no total, no checkout. Must persist: yes, across sessions, per customer. Outside the system: nothing. Not V1: sharing, notifications, merging guest lists. The design took a page and used no tutorial; where it borrowed from the cart was the shape of "a customer-owned list of product references", and that shape is now known as a shape, not as a cart.
- Stuck point: "how do I know which customer is making the request in a server handler?" The cart tutorial had done this silently. Framed as a question, it was one documentation entry — the framework's session helper — and that entry is now understood rather than copied. The next stuck point, "how do I stop a customer from saving the same product twice?", became a uniqueness constraint on (customer, product), found in the database docs and not in any tutorial (Invariants as Tests).
- Same ladder for the chat app: follow a realtime tutorial; modify it so messages persist; rebuild it from memory; then build read receipts, which no tutorial covered, from the requirement "a sender can see which messages the other person has seen". The last rung forced the question "what is the data for read state, and who updates it?" — and that question, not the tutorial, is what got learned (Who Owns This State?).
How you know it worked
What now exists that did not before, and what question you can now ask.
- You have built at least one thing on this stack with no tutorial open and can point to the requirement it came from.
- When stuck, your next action is a question to the documentation rather than a search for a walkthrough.
- You can say which parts of a past tutorial were the tool and which were the tutorial author's choices.
- A new requirement with no tutorial produces a decomposition, not a search.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Could I build this again from an empty project with the tutorial closed — and where would I have to peek?
- ?Which decisions in this tutorial are the tool's and which are the author's?
- ?What is the requirement here, stated without reference to anything I have built before?
- ?When I am stuck, what is the specific question about the tool I am actually asking?
- ?What have I built on this stack that no tutorial showed me?
What can go wrong
- Tutorial abstinence: refusing the first rung and spending days rediscovering a setup that a tutorial would have shown in an hour. The ladder starts with a tutorial; it just does not end there.
- Climbing to "modify" and stopping. Modification proves prediction on a shape you were handed; only building from a requirement proves you can produce the shape.
- Building from requirements and then checking against a tutorial "to see if it is right". A tutorial is one path; yours differing from it is not evidence of error. Check against the requirement and the documentation instead.
- Applying the full ladder to every tool, including ones used once for one call. The ladder is for tools you will build on; for a utility, running and modifying the docs' example is enough.
- The upper rungs are slow: building from requirements takes longer than adapting a tutorial, every time, until it does not. The investment pays back only if the tool stays in use.
- Building without a tutorial produces designs that differ from the community's conventions, and some of those conventions exist for reasons you will meet later.
- The stuck points are uncomfortable by design; a learner who avoids discomfort will go back to the tutorial, and the ladder then measures nothing.
- "Tutorials are the problem." Tutorials are a fine first rung. Dependency is the problem, and it is defined by whether you can leave the first rung, not by whether you stood on it.
- "Once I have built from requirements once, I know the tool." You know the parts of the tool that requirement touched. The next requirement will find the next stuck point; the difference is that you now expect it and know what to do.
- "This is about beginners." Seniors depend on tutorials in unfamiliar areas exactly as beginners do in familiar ones, and the ladder is the same; a senior is simply faster on the upper rungs because the requirement-to-design move transfers across tools.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALFollow, modify, build similar, build from requirements applies to any tool you intend to build on; the same ladder works for a language, a framework, a cloud service or a data pipeline, with "tutorial" meaning whatever walked path you started from.
- TEAM-SPECIFICA solo learner climbs all four rungs; on a team with an experienced member, the upper rungs can be compressed by pairing on the first requirement-driven build, with the experienced person acting as the hint ladder rather than the answer.
- ILLUSTRATIVEThe wishlist, the cart tutorial and the stuck points are invented to show the shape of the ladder; no particular tutorial or framework is being described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Build Without AI" mode at /manifesto/without-ai is the same ladder with an AI in place of the tutorial; the hint ladder there is the one to use when stuck on the top rung.