Choose the next skill by its dependencies
Choose the next skill from the dependencies of a receipt organizer, with clear questions and evidence for each boundary.
Choose the next skill that unblocks a real question in the project you are trying to build. I prefer that rule to starting with the longest available roadmap. A dependency map helps distinguish a prerequisite from an interesting neighboring topic, which matters when a project touches frontend, backend, cloud and AI at once.
A roadmap can suggest useful subjects. It cannot know which assumptions you already understand or which part of your current feature is blocked. The exercise below uses a hypothetical receipt organizer so the dependencies stay concrete.
Write the outcome as behavior
Suppose the intended first release lets a signed-in user upload a private receipt and view it on another device. That sentence is more useful than “learn full stack” because you can ask what must be true for it to work.
The browser needs a way to upload the receipt and display a result. The server needs to identify the caller. Storage needs to preserve the receipt and its owner. A later read must enforce that ownership rule. Deployment must provide configuration and network access without placing credentials in the browser bundle.
The MDN HTTP overview is a useful reference for the request-response boundary. AWS IAM best practices provide a concrete cloud example of identity and least privilege. The IAM details are provider-specific; the learning question about which identity may perform an action applies more broadly.
Draw dependencies as questions
Write a node for each question you cannot yet answer. Then connect a question to the prerequisite it needs. For example, understanding which receipt a request may read depends on knowing how the server identifies the user. Choosing a storage permission depends on knowing which server component accesses storage.
A small map might contain these relationships:
| Question | Needed before answering it |
|---|---|
| How does the server identify the caller? | The application’s authentication approach |
| May this caller view this receipt? | Caller identity and stored ownership information |
| Which service may access stored receipts? | Deployment boundaries and the chosen storage operation |
| What should the browser show after a failure? | The endpoint’s error and retry behavior |
Do not turn every unfamiliar word into a prerequisite. You can learn one authentication flow without studying every identity protocol. You can use a local database before deciding how a cloud database should be operated. The map should expose the next useful dependency, not prove how large software engineering is.
The arrows show reasoning dependencies for this exercise, not a mandatory career order. Another developer may already understand identity and need to study data persistence first. A public, read-only site would have a different map.
Pick a small test for the first blocked node
Imagine that the interface works with a hard-coded user, but you cannot explain how the server distinguishes two accounts. Study that boundary next. Create two fictional identities in a local or isolated test environment and inspect what the server receives for each request.
Write down the identifier the application trusts, where it comes from and how it is validated. Then attempt to request a receipt owned by the other identity. The expected result should be explicit before the request runs. That exercise connects authentication and authorization without pretending they are the same decision.
Once you can explain the result, update the map. Perhaps the next uncertainty is whether a service credential grants access to every receipt. Perhaps it is how an expired session appears in the interface. The next topic follows from the observed gap.
If a prerequisite turns out to be larger than the project can absorb, simplify the project. A local-only receipt exercise can teach persistence while you postpone remote identity. Record that change in scope so you do not later describe the result as a secure multi-user service.
Keep evidence beside the map
A node marked “done” should point to something more specific than a watched tutorial. Keep a short explanation, a request trace, a diagram or an acceptance check. For the ownership node, an example might show one accepted read and one rejected cross-account read, together with the rule that produced them.
This evidence is narrow. Two request cases do not establish complete security. They do show whether you can apply the particular rule you are studying. A good map makes that limitation visible instead of turning a checked box into a claim of expertise.
Keep a separate list of interesting topics that are not current dependencies. A different frontend framework, a new vector database or a complex deployment platform can wait there. Separating curiosity from prerequisites lets you preserve the idea without giving it control over the current project.
Revisit the map when the product changes
Suppose the next release adds shared receipt folders. The old ownership rule no longer describes the whole product. You now need questions about membership, permission changes and what happens to an already-open editor after access is revoked.
That is a reason to revise the map rather than accuse the first version of being incomplete. It was designed for a private-receipt outcome. Keep the earlier assumptions visible, add the new dependencies and choose the first behavior you cannot yet explain. The map is useful when it helps you decide what to investigate next, including when the right decision is to narrow the feature.
Distinguish a prerequisite from an implementation preference
A dependency map can become misleading if it treats your favorite tool as a necessary step. To enforce access to a receipt, the application needs a way to identify the caller and decide whether that caller may read the requested object. It does not necessarily need a particular frontend framework, container orchestrator or database vendor.
Write the dependency first as a capability. “The server can determine the authenticated account” is a requirement of the example. The chosen session library is one implementation decision. If the map says “learn library X” without naming the capability, you may mistake replacing the library for resolving the underlying question.
The same distinction applies to deployment. A hosted database, a local database and a managed storage service have different operating requirements. Choose the environment that lets you investigate the intended behavior, then record which production concerns remain outside the exercise.
Use a worked ordering example
Suppose the receipt organizer already has a working upload form, but the server assigns every file to a hard-coded account. You also want searchable receipts, a mobile interface and a cloud deployment. All four topics are interesting; they are not equally urgent for the intended private multi-user release.
| Candidate learning task | Current dependency | First useful artifact |
|---|---|---|
| Identify the server-side caller | Blocks account-specific access | Two fictional identities produce distinguishable authenticated requests |
| Enforce receipt ownership | Depends on caller identity and stored owner | An allowed read and a rejected cross-account read |
| Search receipt text | Depends on scoped receipt access if results are private | A query that cannot reveal another account’s document or snippet |
| Add a mobile interface | Reuses the request and access contract | The same permitted operation from another client |
| Deploy to cloud | Adds workload identity and networking | The existing contract exercised with deployed configuration |
For this goal, caller identity is the first blocked capability. A search feature built before ownership rules may need substantial rework, and a mobile interface could reproduce the same insecure request pattern on another device. The ordering follows the promised private-user behavior, not a claim that mobile or search is inherently an advanced topic.
The graph also reveals work that can proceed independently. You can study a mobile layout with fictional local data while the API access contract is being designed. Keep that exercise labeled as an interface prototype until it uses the verified request path.
Combine small artifacts instead of collecting completion badges
After the identity exercise, do not mark “authentication” mastered. Keep the exact request evidence and its assumptions. Perhaps the local setup uses short-lived sessions but has not yet handled expiry. That is enough to support the next ownership exercise under the stated conditions, while expiry remains an unresolved case.
When ownership works, reuse those two accounts in the search exercise. Search results may reveal titles and snippets even if the document-detail endpoint is protected. The new artifact should show that the query applies the intended scope, not merely that clicking a result eventually produces an access error.
This reuse gives the learning path continuity. Each completed question supplies evidence the next question depends on. It also makes regressions visible: a search refactor that drops the account filter can violate a rule established earlier even if the new feature appears to work for the primary account.
Keep tooling knowledge on its own branch
The 2026 Missing Semester syllabus includes command-line work, debugging, version control, shipping code and agentic coding. It is an example of a curriculum that makes development tools explicit rather than assuming students acquire them automatically. Its existence does not mean every tool lesson must come before your first application feature.
Add tooling to the dependency map where it removes a real obstacle. If you cannot inspect a request or reproduce a failure, learning the relevant debugging tool can unlock progress. If version-control confusion makes every experiment difficult to undo, a small Git exercise has immediate value. An unrelated editor customization can remain a separate curiosity project.
Revise the graph when a dependency turns out to be wrong
You may discover that a planned prerequisite was unnecessary. Perhaps the first receipt viewer can use an existing authenticated API, letting you focus on access-aware interface behavior before learning server identity in depth. Update the map to reflect that available contract, and be clear about which part another system currently supplies.
You may also find a missing dependency, such as source retention rules before adding text extraction. Add it because the feature requires a decision about stored content, not because the map needs another box. A good dependency graph is allowed to change when evidence improves. Its purpose is to choose a useful next action while keeping the limits of the current application visible.