Teach Me Only What I Need
If the learner needs a cart, do not hand them a data structures course. An array, a map to compare it with, a loop, a conditional and a function are the whole bill — and then the cart. The rest arrives with the concept that needs it, which is when it will stick.
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.
A learner is stuck on the cart because of a foundation. How much do you teach them — and what is the strongest argument for teaching more than they asked for?
You are helping someone — or you are the someone — who cannot write findItem. Every instinct says the honest answer is "you need to learn data structures" and the honest link is the front page of a DSA course. It is a lot, and it is not wrong, and the cart is still not written.
Prescribe the course. Send them to the arrays chapter, then the hash-map chapter, then complexity, then recursion, because each is genuinely related and it feels irresponsible to leave any out. "You will need all of it eventually" is true, so it seems to justify all of it now.
The cart is what made the learner willing to learn arrays, and the cart is now weeks behind a syllabus. By the hash-map chapter the willingness has gone and the arrays chapter has faded, because nothing was built with it.
- The cart is what made the learner willing to learn arrays, and the cart is now weeks behind a syllabus. By the hash-map chapter the willingness has gone and the arrays chapter has faded, because nothing was built with it.
- The learner cannot tell which parts mattered. Everything was presented as necessary, so the loop-and-compare that findItem needs weighs the same as binary search, which the cart never uses. Equal weight is no weight.
- The course cannot be tested against the cart. Each chapter has its own exercises on its own arrays; the learner finishes them and returns to
cart.items.findwith the same question, because the course never saw that line.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Teach the bill, not the catalogue. Ask what the cart actually stands on and write those items down — for V1: an array, a loop over it, a conditional inside the loop, a function to hold it, and a map to compare against the array when the representation question is asked. That is the entire foundation the cart requires, and each item can be taught in the time it takes to write it on cart data.
- Teach each item at the moment the cart needs it and prove it with the operation that needs it. The loop is taught when findItem needs it and proven by findItem. The map is taught when "why an array?" is asked and proven by writing addItem both ways and reading the complexity of each. Nothing is taught ahead of its operation.
- Then return to the cart, and let the next concept bring the next bill. Search brings string matching; a rate limiter brings time windows; a job queue brings a queue. Breadth arrives one concept at a time, each item attached to the thing that needed it — which is why it stays.
- Hold the opposing view honestly. There is a real case for foundations first — it is stated below as a contested scope — and the strongest version of it is not "learn everything" but "a learner who has never seen a map cannot ask the representation question at all". Answer it by putting the map on the bill, as a comparison, at the moment that question is asked.
The bill, walked down
The Why Ladder below takes the claim "you need to learn data structures" and asks why until the actual requirement appears. The device is not "courses are bad": the last field says exactly when the claim was right, and the contested scope above gives that side its strongest form.
“To write this cart you need to take a data structures course.”
- ↓Why a whole course? Because the learner cannot write findItem, and findItem is about arrays.
- ↓Why does findItem need the course? It needs a loop over an array with a comparison and an early return — one section of one chapter.
- ↓Why not just that section? Because they will also need to know why an array and not a map — which is one more structure, taught as a comparison, not a chapter.
- ↓Why is the rest on the list? Because it is related and will be needed someday. Which is true, and is a reason to schedule it after a few concepts, not before the first.
the claim was right when The learner has no pressing concept, wants breadth, and has already built two or three things just-in-time and noticed the jaggedness; or a cohort is being onboarded together and the same foundations serve everyone at once. Then the course is the right move, and its chapters will land on problems the learner has already met.
One foundation, through the whole cart
Teaching a foundation "just in time" is a vertical slice through the learning: one primitive, carried from a scratch experiment up to a working operation and a passing example. The slice proves the primitive was learned in a usable form. It does not prove breadth — and the device says so.
- Scratch experimentTwo entries in an array; a loop prints "laptop" then "mouse" — the primitive in isolation, on cart data.
- The rungfindItem: the same loop with a comparison and an early return; findItem([Laptop × 1], "laptop") returns the entry, findItem([], "laptop") returns nothing.
- The operationaddItem calls findItem and branches; the concept's example [Laptop × 1] + add Laptop → [Laptop × 2] passes.
- The comparisonThe same addItem over a map, where find is a key lookup; the learner reads O(n) beside O(1) average and says which the V1 cart wants and why.
Two ways to answer "I can't write findItem"
The comparison is between two honest responses. Both point at DSA; the difference is whether the pointer is a page or a section, and whether the cart is waiting at the end of it.
"You should go through Arrays, Hash Maps, Complexity and Recursion first — here is the roadmap." True, complete, and the cart is behind four chapters with exercises on someone else's data.
"findItem is a loop with an early return — read the iterating section of Arrays, write the loop on your two cart entries, then come back and we will write findItem. When you ask why not a map, we will build addItem both ways and compare." Two links, two experiments, the cart at the end.
The bill attaches each foundation to the operation that proves it, so what is learned is retrievable when the next concept needs it; the catalogue attaches nothing and is forgotten at the same rate it was read. The catalogue is right later, for breadth, once several bills have been paid.
The implementation ladder
Concept, examples, pseudocode, code, tests, production — for the concept this lesson is about. Code is the fourth tab, not the first.
Shopping Cart = A temporary collection of products the user intends to purchase, held between browsing and checkout.
- Does a cart have identity? Yes, weakly. Two carts with the same items are still two carts, because each belongs to someone and will become a different order. It needs an id once it leaves memory; in memory the variable is the identity.
- Who owns it? A shopper — a logged-in user or an anonymous session. The owner is part of the state because "my cart" has to be findable again.
- How long does it exist? From the first add until checkout or abandonment. Whether it survives a reload, a closed browser or a login is not a property of the concept; it is a persistence decision made later, and each answer changes where the cart lives.
- Should it survive reload? Usually yes for a store, usually no for a demo. V1 in memory says no; V2 browser storage says yes on one device; V3 server storage says yes everywhere the user is logged in.
- Should it survive login? Only if an anonymous cart and a logged-in cart are merged — a rule that does not exist in V1 and appears as a modification later.
- itemscollection of CartItemkeepThe cart is its items; without them nothing else means anything.
- items[].productIdidkeepThe reference to what is being bought. The catalog owns the product; the cart only points at it.
- items[].quantityinteger > 0keepTwo laptops is one entry with quantity 2, not two entries — the rule "one entry per product" needs a quantity to hold.
- owneruser id or session iddependsSo the cart can be found again by the person it belongs to.
- items[].productNamestringderiveIt would be convenient to render the cart without a catalog lookup.
- items[].pricemoneydependsThe total needs a price per item.
- totalmoneydropEvery screen shows the total.
- currencycodedependsPrices need a currency to be added.
- createdAttimestampdropAbandoned carts might be expired or emailed about.
- update Add item — the updated cart
- delete Remove item — the updated cart
- update Change quantity — the updated cart
- read View items — the list of entries — product id and quantity — for rendering
- domain Calculate total — the sum of price × quantity over the entries
- delete Clear cart — the empty cart
- • Every quantity is greater than zero.
- • One logical entry per product.
- • The total is never negative.
- • An unknown product cannot be added.
- • Quantity cannot exceed available stock — if inventory is enforced here.
How to do it
Most important first.
- Before pointing at any course, write the bill for this concept: the primitives in its graph that the learner has not marked (The Prerequisite Graph). If it is more than five items, the concept is probably not the right first concept.
- For each item on the bill, name the cart operation that will prove it and the four-line experiment on cart data that teaches it (When the Rung Below Is a Foundation).
- Link to the DSA lesson for the structure, and say which section: "Arrays — the part on iterating and finding; skip sorting for now" (A Reading Strategy for an Unfamiliar Library).
- Put the alternative structure on the bill as a comparison, not a prerequisite: array cart against map cart, complexity annotated, one requirement that would flip it (Array Cart vs Map Cart).
- When the cart is done, ask what the next concept's bill is, and notice how much of it is already paid.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The bill for the V1 cart, for a learner who knows variables and conditionals: (1) arrays — make one with two entries, read one; (2) loop — visit each entry; (3) function with an early return — findItem; (4) the map — addItem written over a
Map<ProductId, CartItem>, with "find" becoming a key lookup, O(1) average against the array's O(n) scan. Four items. Recursion, sorting, binary search, trees: not on the bill. - Taught at the moment of need. Arrays and the loop arrive when findItem does; the map arrives when the learner asks "why not just use a dictionary?" during the representation step — and is taught as a second addItem, so the comparison is between two carts that both work, not between two chapters.
- The next concept, "search products by name", brings its own bill: substring matching, case folding, and — once the catalog is large — the question of an index. Arrays and loops are already paid. The learner meets the search index with a reason to want it, which the DSA course's chapter on it could not have supplied.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The foundation list for the cart fits in one line and every item names the operation that proves it.
- The learner can say which DSA lesson they read and which section, and why that section and not the page.
- The map was met as an alternative cart with annotated cost, not as a chapter.
- The next concept's bill is shorter than the cart's was, because most of it is paid.
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.
- ?What does this concept actually stand on — and is every item on the list provable by one of its operations?
- ?Which DSA section does this operation need, and where does the page stop being about my problem?
- ?What alternative structure must be on the bill so that the representation question can be asked at all?
- ?What did the last concept pay for that this one gets free?
What can go wrong
- Teaching so little that the representation question cannot be asked. A learner who has only ever seen the array cannot compare it with anything; the map belongs on the bill even though V1 does not use it.
- Teaching just-in-time and never consolidating. Five concepts later the learner has five bills paid and no picture of how the structures relate; a pass through the DSA roadmap at that point is the right time for breadth, not the wrong one.
- Mistaking the bill for a cap. "Only what I need" is about order and attachment, not a limit on curiosity; a learner who wants to read the whole arrays page after findItem works should.
- Applying it to a team onboarding where the codebase uses everything. On a mature codebase the "concept" is the system, and the bill is long; the move still applies, but the items are the system's own primitives, not the language's.
- Just-in-time foundations produce a jagged map of the field; the learner knows arrays deeply and heaps not at all until a concept needs one. Breadth has to be scheduled on purpose, later.
- Writing a per-concept bill costs a teacher more than sending a link, and it is the cost that makes the link land.
- Putting the map on the bill as a comparison adds a second implementation to a concept whose V1 uses one; it is the price of being able to answer "why this data structure?"
- "So a DSA course is a waste of time." It is the wrong first move for someone stuck on a cart, and the right move for someone who has built several concepts and wants to see the structures together. Order, not value.
- "Only what I need means only the array." It means the array and the thing the array is compared with; a choice with one option is not a choice, and the representation lesson depends on there being two.
- "This is the same as learning from tutorials." A tutorial teaches its own cart; the bill is written from your cart's graph. The difference is which problem is pulling.
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.
- CONTESTEDThe foundations-first camp holds, in its strongest form, that a learner who meets arrays only through a cart learns a cart-shaped idea of arrays and cannot recognise the same structure inside a queue or a search index; that comparing representations requires already knowing the candidates; and that the just-in-time learner's knowledge is jagged in ways that surface as poor choices later, when nobody is checking. This lesson answers by putting the alternative on the bill and scheduling breadth deliberately after several concepts — but that answer is a judgment, and a learner with time and no pressing project may reasonably take the course first.
- TEAM-SPECIFICFor a solo learner with a project, the bill is the right unit. For a bootcamp cohort or a team onboarding on a large codebase, some breadth up front is efficient because the same foundations are needed by everyone at once, and the "concept that pulls" is the codebase itself.
- ILLUSTRATIVEThe four-item bill, the weeks and the imagined syllabus are for the shape of the argument; the array-versus-map costs are the concept's own annotated complexities.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto argues that tools and courses accelerate understanding but must not replace it; this lesson is that line applied to curricula.