The Project | About Us | Contribute | Donations | License

HOME

You started this course writing console.log('Hello, Taller Nómada'); without really knowing what a variable was. You finish with a product of your own: planned, built in layers, persisted with migrations, tested at three levels, deployed over HTTPS with continuous deployment, documented with ADRs and defensible in an interview. Between those two sentences there are eleven modules and a good many hours of your own. This last lesson does not teach a new technique: it does three different and necessary things. First, an honest stocktake of what you know now — competency by competency, module by module — and, with the same honesty, what this course does not cover, because knowing your own gaps is as valuable as knowing your own capabilities. Second, the map of what comes next: TypeScript, Node.js and the backend, mastering a framework properly, tooling and the platform, going deeper into the web and choosing a specialization — each path with what it is, why it matters, how to start and how much time it asks for, with no exaggeration. And third, the most important thing and the least often taught: how you keep learning when there is no longer a course telling you what comes next, how to stay current without burning out, and what to do with all of this in career terms, with honesty about the state of the market. You will finish with a six-month roadmap adapted to your real availability. This is the last lesson: it links to nothing afterwards, because what comes after is yours to decide.

The stocktake: what you know now
What this course does not cover
The map of the paths
TypeScript: static typing
Node.js and the backend
A framework in depth
Tooling and the platform
Going deeper into the web platform
The specializations
How you keep learning when there is no course
Reading other people's code and contributing
How to stay current without burning out
Why the fundamentals do not expire
The six-month roadmap
Career: portfolio, CV and interviews
The first job and learning on the job
Common Mistakes and Tips
Exercises
Conclusion

The stocktake: what you know now

It is easy to finish a long course with the feeling that "you do not know that much". It is an almost universal impression and almost always false: the cause is that you have been raising the bar of what counts as "knowing" at the same rate as you were learning.

This table is the real inventory. It is not a syllabus: it is a list of competencies, written as things you can do.

Module	What you can do now
M1 · Introduction	Set up a development environment, understand what a JavaScript engine does, declare and use variables with judgment, choose the right type, and read an error message without freezing
M2 · Control flow	Express business rules with readable conditionals, walk through data with the right loop, and handle errors with `try/catch` distinguishing the expected from the exceptional
M3 · Functions	Break a problem into functions with a single responsibility, use closures to encapsulate state, write higher-order functions, and solve recursive structures
M4 · Objects and arrays	Model entities, transform collections with `map`, `filter` and `reduce`, destructure, copy without side effects and serialize to JSON
M5 · Advanced	Design classes with real encapsulation, organize code into modules, master asynchrony with promises and `async/await`, and explain the event loop and microtasks
M6 · DOM	Build interfaces without a framework: selection, creation, events, delegation, list rendering and accessible forms with validation
M7 · Browser APIs	Persist data, talk to an API with robust `fetch`, use WebSockets, turn a site into a PWA with a service worker, and know the essential APIs
M8 · Testing	Debug methodically, maintain quality with ESLint and Prettier, write unit, integration and end-to-end tests, and use test doubles
M9 · Performance	Measure before optimizing, set a budget, optimize code, manage memory, manipulate the DOM efficiently and split the load
M10 · Frameworks	Understand why they exist, know React, Redux, Vue and Angular at a working level, and choose with judgment rather than by fashion
M11 · Project	Plan a product, build it in layers, persist and synchronize data, set up a testing strategy and CI, deploy securely, and present and defend it

And the cross-cutting competencies, which are worth the most and which no syllabus lists:

Competency	Where you acquired it
Turning a problem into a data model and a set of rules	01-08, 11-01
Deciding with judgment and being able to defend the decision	10-06, 11-01, 11-06
Measuring before opining	All of M9, 11-04
Debugging methodically instead of blindly	08-01, 11-02, 11-04
Writing code somebody else can maintain	M8, 11-02, 11-06
Finishing things	All of M11

That last row is, without any exaggeration, the one that will set you apart the most. Vast numbers of people start projects; very few take them from plan to documented deployment.

A way to check for yourself: go back and read the code you wrote in Modules 1 and 2. If it looks improvable — and it will — that is objective proof you have progressed. Discomfort when looking at your own old code is the most reliable sign of progress there is in this profession, and it never goes away: two years from now you will feel the same about what you write today.

What this course does not cover

Just as important, and considerably rarer to find written down.

Area	What has not been covered	How much it matters
Static typing	TypeScript: types, generics, inference	A lot in teams and in the job market
Backend	Node.js as a server, REST APIs, databases, authentication	A lot if you want to be full-stack or understand the whole system
A framework properly	Only the fundamentals of four were covered; none in depth	A lot for most job listings
Modern CSS	Grid, container queries, design systems, animations	Quite a bit: it has been used, not taught
Databases	Relational modeling, SQL, indexes, transactions	A lot in backend
Algorithms and data structures	Complexity, graphs, balanced trees, dynamic programming	Medium: it matters in some interviews
Web security in depth	OWASP, CSRF, sessions, applied cryptography	A lot in real production
Architecture at scale	Micro-frontends, monorepos, design systems	Medium: it arrives with team size
DevOps	Docker, Kubernetes, infrastructure as code, the cloud	Medium-high depending on the role
Mobile	React Native, Capacitor, native apps	Depends on your goal
Real teamwork	Peer reviews, methodologies, product management	A lot, and it is only learned by working

That last row deserves an honest note: there are things you do not learn on any course. Working with code somebody else wrote four years ago, negotiating scope with a non-technical person, maintaining a system nobody remembers anything about, or reviewing a colleague's code without damaging the relationship. They are learned by working, and there is nothing wrong with not knowing them yet. What does help is knowing they exist and not confusing "I have not mastered them" with "I am not good enough".

And a warning about the list. Seeing it in full produces a certain vertigo. You do not have to learn everything, and certainly not all at once. The next section organizes this into paths, and section 14 turns it into a six-month plan with one main direction.

The map of the paths

flowchart TD
    A["You know JavaScript<br/>and you have finished a product"] --> B["TypeScript<br/><i>1-2 months</i>"]
    A --> C["A framework<br/>in depth<br/><i>2-3 months</i>"]
    A --> D["Node.js<br/>and backend<br/><i>3-4 months</i>"]

    B --> E["Product<br/>front-end"]
    C --> E
    C --> F["Front-end<br/>specialist"]
    D --> G["Full-stack"]
    B --> G

    A --> H["The web platform<br/>in depth<br/><i>continuous</i>"]
    H --> I["Accessibility<br/>Performance<br/>Security"]

    A --> J["Tooling<br/>and platform<br/><i>cross-cutting</i>"]
    J --> G
    J --> K["Tooling / DevEx"]

    style A fill:#dcfce7,stroke:#16a34a
    style B fill:#dbeafe,stroke:#2563eb
    style C fill:#dbeafe,stroke:#2563eb
    style D fill:#dbeafe,stroke:#2563eb

The three blue paths are the main ones, and the recommended order is this:

TypeScript first, because it is the cheapest (you start today, on your own project) and because it multiplies the value of everything else.
A framework in depth next, because it is what appears most in job listings and because you already have the judgment from 10-06 to choose which one.
Node.js when you want to understand the whole system, or if the backend appeals to you.

The gray paths — the web platform and tooling — are not alternatives: they are continuous. You always advance on them, in parallel, a little each month.

And the rule that governs the whole map, worth writing somewhere visible:

Choose one main direction for the next six months. One. The others will still be there.

The most common mistake on finishing a course is starting four things at once, having three months of the feeling of progress, and mastering none. One at a time, in depth, is faster even though it does not look it.

TypeScript: static typing

4.1 What it is and why it matters

TypeScript is JavaScript with types checked before you run. You write it almost identically, it compiles to JavaScript, and the browser never sees it.

What changes is not the syntax: it is when you find out about the errors.

// Without types: this fails in production, on a Tuesday, on somebody's phone
function hoursOf(task) {
  return task.estimatedHours.toFixed(1);   // 💥 if estimatedHours is undefined
}

// With types: it fails as you write it, in your editor, underlined in red
interface Task {
  id: number;
  title: string;
  estimatedHours: number;
  assigneeId: string | null;
}

function hoursOf(task: Task): string {
  return task.estimatedHours.toFixed(1);   // ✅ the compiler guarantees it exists
}

Why it changes teamwork, which is its main value and the least obvious one:

Without types	With types
To know what a function returns, you read it	The signature says so, and the editor shows you
When changing a field, you search for usages with `grep` and hope	The compiler lists every place that has to be touched
Documentation goes out of date	Types cannot go out of date: they would not compile
Refactoring is scary	Renaming is a safe editor operation
"Can this be `null`?"	The answer is written down

That second point is the one you notice most in a real project. Changing assignee: string to assigneeId: string | null in your project meant reviewing every affected place by hand; with TypeScript, the compiler gives you the complete list and misses none.

4.2 The cheap way in: `// @ts-check` and JSDoc

You do not have to migrate anything to start. TypeScript can check your current JavaScript using JSDoc comments, which you already know from 08-02.

// @ts-check
/**
 * Computes the open hours of a list of tasks.
 * @param {Array<{status: string, estimatedHours: number}>} tasks
 * @param {string} [assigneeId] - If given, filters by assignee
 * @returns {number} Hours from unfinished tasks
 */
export function openHours(tasks, assigneeId) {
  return tasks
    .filter((t) => t.status !== 'done')
    .filter((t) => !assigneeId || t.assigneeId === assigneeId)  // ⚠️ error
    .reduce((sum, t) => sum + t.estimatedHours, 0);
}

With that single // @ts-check line at the top of the file, your editor already underlines that t.assigneeId does not exist in the declared type. Zero configuration, zero compilation, zero changes to the code that runs.

The next step is a jsconfig.json enabling it for the whole project:

{
  "compilerOptions": {
    "checkJs": true,
    "strict": true,
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "noEmit": true
  },
  "include": ["src/**/*.js"]
}

This is the path I recommend, and it is not the usual one: learn TypeScript on your own project, typing the domain first, with JSDoc and no compilation. It is gradual, reversible and applied to code you know.

4.3 The gradual migration

When you want to take the leap to real .ts:

Step	What you do	Duration
1	`// @ts-check` + JSDoc in `domain/`	1 week
2	`jsconfig.json` with `checkJs` across the project	1 day
3	Install TypeScript; rename `domain/*.js` to `.ts`	1 week
4	`data/` and `application/`	1–2 weeks
5	`view/` (the one that will tolerate the most `any` at first)	1–2 weeks
6	Enable full `strict` and eliminate the `any`s	Ongoing

Always start with the domain. It is where types contribute the most (the entities and the rules), where the code is most stable, and where there are no unavoidable DOM anys.

4.4 An example of your own model, typed

// src/domain/types.ts
export type Status = 'pending' | 'in-progress' | 'done';
export type Priority = 'high' | 'medium' | 'low';
export type Role = 'coordination' | 'team' | 'guest';

export interface User {
  readonly id: string;
  name: string;
  initials: string;
  role: Role;
  active: boolean;
}

export interface Task {
  readonly id: number;
  title: string;
  assigneeId: string | null;
  reviewerId: string | null;
  priority: Priority;
  readonly status: Status;          // only changes through changeStatus()
  tags: readonly string[];
  estimatedHours: number;
  dueDate: string | null;
  parentTaskId: number | null;
  readonly createdAt: string;
}

// R6: the transition matrix, checked by the compiler
export const TRANSITIONS: Record<Status, readonly Status[]> = {
  'pending': ['in-progress'],
  'in-progress': ['done', 'pending'],
  'done': ['in-progress']
} as const;

export interface Repository {
  listTasks(): Promise<Task[]>;
  saveTask(task: Task): Promise<Task>;
  deleteTask(id: number): Promise<void>;
  listUsers(): Promise<User[]>;
}

Notice four things that file achieves for free:

Status and Priority as literal unions make it impossible to write 'finished' by mistake. It is R6 and the closed-set validations, checked by the compiler instead of at runtime.
readonly documents and enforces which fields are not touched directly. It is the encapsulation from 05-03 expressed in the type.
Record<Status, readonly Status[]> guarantees that the transition matrix covers every status. If tomorrow you add 'archived', it does not compile until you define its transitions. That is a business rule verified by the compiler.
interface Repository is your contract from 11-02, now checked: if an implementation forgets a method or changes a signature, it does not compile. The contract test is still necessary for behavior, but the shape is guaranteed by the type.

4.5 How to start and what it asks for


How to start	`// @ts-check` in one file of your domain, today. Then `jsconfig.json`. Then the gradual migration
What to study	Basic types, unions, interfaces versus `type`, generics, `unknown` versus `any`, type guards, utilities (`Partial`, `Pick`, `Omit`, `Record`)
How long	2–3 weeks to be productive. 2–3 months for fluency with generics and advanced types
When you will feel the benefit	The first big refactor. That is where it pays for itself
What NOT to do	Reaching for `any` as soon as something gets complicated. Every `any` is a hole that voids the guarantee down the chain

Node.js and the backend

5.1 What it is and why it matters

Node.js is JavaScript outside the browser. The same language, the same event loop you studied in 05-07, the same promises — but with access to the file system, the network and processes.

What changes:

Browser	Node.js
`window`, `document`, the DOM	They do not exist
`localStorage`	The file system and databases
`fetch` to request	A server that answers requests
The user controls the environment	You control the environment
Nothing is secret	Keys are safe
One user at a time	Many at once, with shared state

The last two rows are the important ones, and you already ran into them in 11-05: validation has to be on the server because the client is controlled by the user, and secrets can only live where the user cannot reach.

5.2 The path, in four steps

Step 1 · A basic HTTP server. With Express or Fastify, understanding routes, methods, headers, bodies and status codes:

import express from 'express';
import { Task } from '../src/domain/task.js';           // ← YOUR domain, unchanged
import { ValidationError, RuleError } from '../src/domain/errors.js';

const app = express();
app.use(express.json({ limit: '100kb' }));

app.post('/v1/tasks', async (request, response, next) => {
  try {
    const task = new Task(request.body);                // R1-R15 on the server
    response.status(201).json(await repository.save(task));
  } catch (error) {
    next(error);
  }
});

// Centralized error handler: translates domain errors to HTTP
app.use((error, _request, response, _next) => {
  if (error instanceof ValidationError) {
    return response.status(400).json({ code: 'VALIDATION', field: error.field, message: error.message });
  }
  if (error instanceof RuleError) {
    return response.status(409).json({ code: 'RULE', message: error.message });
  }
  log(error);
  response.status(500).json({ code: 'INTERNAL', message: 'Internal error' });
});

That import of your own domain is the reward for the whole module's architecture. The fifteen rules, written and tested once, running on both sides. It is not an idealized example: it works because domain/ never imported anything from the browser.

Step 2 · A database. SQLite to start (one file, zero installation), PostgreSQL when you need it. What you have to learn: relational modeling, foreign keys, basic SQL, indexes, and why transactions exist.

Step 3 · Authentication and authorization. The distinction 11-05 raised: authentication is who you are; authorization is what you can do. Passwords with a slow hash (bcrypt or argon2, never MD5 or plain SHA), sessions with an HttpOnly cookie or tokens, and role-based permissions — your R15, now enforced where it cannot be bypassed.

Step 4 · Production. Environment variables, structured logging, rate limiting, CORS, backups, containers.

5.3 How to start and what it asks for


How to start	Replace your `json-server` with a 100-line Express of your own that uses your domain
Next project	Your project's real backend: database, authentication and deployment. Turn your v1.0 into v2.0
How long	1 month for a CRUD with a database. 3–4 months for something with authentication, deployed with judgment
What NOT to do	Start with microservices or GraphQL. A well-built monolith first

A note of honesty about databases: it is the part where most people underestimate the effort. Writing a SELECT is easy; modeling well, understanding what an index does, and knowing why a query takes two seconds is a world of its own. It is worth it and it takes time.

A framework in depth

6.1 Why properly master one

In 10-06 you learned to choose. Now it is time to master, and those are different things.

Knowing four frameworks at tutorial level has a surprisingly low value:

Level	What you can do	Market value
Tutorial (10 h)	Follow an example, understand the vocabulary	Low
Working (100 h)	Build a complete application	Medium
Deep (500+ h)	Debug odd problems, make architectural decisions, optimize, train others	High

The difference between the second and the third is where the professional leap is. And it is only achieved with one, not by splitting your time across four.

6.2 Which one to choose

Go back to the weighting table from 10-06 and apply it to yourself, not to a project:

Criterion	Weight for your personal decision
Job listings in your city or in the remote market you target	High: look at real listings, not global surveys
Which one felt most comfortable in Module 10	Medium: motivation matters
The sector you want to move into	Medium: there are correlations by sector
Target company size	Low-medium

A concrete one-hour procedure, and it is the best hour you can invest in this decision: open a job board, filter by your city and by "junior", and count the mentions of each framework in the first fifty listings. That number, for your market, is worth more than any global trend.

6.3 What "in depth" means

It is not learning more API. It is this:

Level	What you master
Fundamentals	Components, state, props, lifecycle, events
Patterns	Composition, lifting state, containers versus presentation, your own hooks or composables
Ecosystem	Routing, global state, forms, requests and server caching
Testing	Testing Library with that framework, and what not to test
Performance	When it re-renders, memoization, virtualized lists, code splitting
Architecture	Folder structure, boundaries, where the business logic lives
Internals	How reconciliation or reactivity works on the inside

The last two rows are what separate somebody who uses a framework from somebody trusted to decide how it is used in a team. And notice that you already know most of those rows conceptually: performance (M9), testing (M8), architecture (M11). What you learn is how they are expressed in that tool.

6.4 How to start and what it asks for


How to start	Rewrite your own project with the chosen framework. You already know the domain: only the view changes
Afterwards	A new project with the full ecosystem: routing, state, forms, requests
How long	2–3 months for a solid working level. 6–12 months of real use for depth
The advantage you have	10-06 showed that `domain/rules.js` was identical across all four. Your domain is reused as is
What NOT to do	Jump from framework to framework every two months. Pick one and stay long enough to reach the hard parts

Tooling and the platform

It is not a path in itself: it is what accompanies any of the others and what separates somebody who programs from somebody who delivers software.

Area	What to learn	Priority	Time
Advanced Git	Interactive `rebase`, `bisect`, `cherry-pick`, `reflog`, conflict resolution, workflows	High	2 weeks
The terminal	Bash or Zsh, pipes, `grep`, `find`, `sed`, your own scripts	High	Ongoing
CI/CD	You already have the basis from 11-04. Matrices, caches, environments, approvals	Medium	2 weeks
Docker	Images, containers, `docker-compose`, why it exists	Medium-high	3 weeks
The cloud	One provider, the basic services: compute, storage, database, networking	Medium	1–2 months
Observability	Structured logging, metrics, traces, alerts	Medium	2 weeks

Advanced Git has the best effort-to-benefit ratio in the whole table, and it is the most underrated. Two weeks of study and practice give you capabilities you will use every day for your whole career:

Command	What it is genuinely for
`git bisect`	Automatically finding which commit broke something. It only works well if your commits are small — which you have been doing since 11-02
`git rebase -i`	Cleaning up the history before merging: squashing, reordering, rewriting messages
`git reflog`	Recovering work you thought was lost. Almost nothing is truly lost in Git
`git worktree`	Working on two branches at once without `stash`
`git blame`	Finding the commit — and the ADR — that explains an odd line

That last one closes the circle with 11-06: git blame on a strange line takes you to the commit, and the commit body takes you to the why. That is why they are written that way.

Docker in one sentence, because it is usually explained badly: it is the way of packaging your application with everything it needs to run — the Node version, system dependencies, configuration — into something that behaves the same on your laptop, in CI and in production. It solves "it works on my machine" definitively.

Going deeper into the web platform

This path is different from the others: it never ends and it always pays off, because what you learn here does not depend on any tool.

Area	What to go deeper into	Why
Accessibility	WCAG 2.2, real ARIA, screen readers, audits	A growing legal obligation and a specialization with demand and little supply
Security	OWASP Top 10, XSS, CSRF, sessions, advanced CSP, the supply chain	Everybody needs it, almost nobody masters it
Performance	Web Vitals in depth, profiling, networking, rendering	Direct, measurable business impact
Front-end architecture	Design systems, monorepos, micro-frontends, contracts	It arrives with team size
Web Components	`customElements`, Shadow DOM, templates	The only thing that survives every framework
Modern CSS	Grid, container queries, layers, `:has()`, custom properties	It has been used in the course, not taught

About OWASP, because it is the most important on the list and the least known: it is a list of the ten most critical security risks in web applications, updated periodically and used as a reference across the industry. You already know several of its topics — XSS (06-02, 11-03), insecure configuration (11-05), exposed secrets (11-05) — but there are others that have not been touched: broken access control, cryptographic failures, injection, and supply-chain security (the dependencies you install).

About Web Components, with the nuance from 10-06: they are the browser standard for creating reusable custom elements, with connectedCallback as the lifecycle, attachShadow to isolate styles and CustomEvent to communicate — everything you already know, but standardized. Their real value is not replacing frameworks, but working anywhere: a component that has to live in a React site, an Angular one and one with nothing at all.

How to study this path: not in two-month blocks, but one topic a month, in parallel with everything else. One month of serious accessibility applied to your project. Another of OWASP with an audit of your own. Another of modern CSS redoing your interface. It is cumulative and it does not expire.

The specializations

As you progress, the question of what you want to become appears. You do not have to answer it today, but it is worth knowing the map.

Specialization	What you do	What you need	Market
Product front-end	Interfaces, experience, collaboration with design	One framework in depth, CSS, accessibility, product sensibility	Broad
Full-stack	Front and back, the whole system	A framework + Node/another language + a database + deployment	The most in demand in small and medium companies
Web performance	Measuring and optimizing experiences	M9 in depth, networking, browsers, tooling	Niche, well paid
Accessibility	Auditing, fixing, training	WCAG, ARIA, screen readers, regulation	A growing niche, few candidates available
Tooling / DevEx	Internal tools, CI, bundlers	Node, Git, CI/CD, empathy with developers	Niche, in medium and large companies
Mobile with web tech	Applications with web technology	React Native or similar + the platforms	Broad
Platform engineering	Infrastructure for teams	Cloud, containers, networking, automation	High, requires experience

Three things worth knowing about this:

You do not have to choose now. Most people discover their specialization while working, by noticing which problems they gravitate towards.
Niche specializations have fewer listings but far less competition. Somebody who genuinely knows accessibility is hard to find; somebody who knows React is not.
Starting as a generalist is normal and healthy. Specializing too early, without having seen enough, is usually a poorly informed decision.

How you keep learning when there is no course

Of the whole lesson, this section is the one that will most determine where you are in three years. Because from tomorrow nobody is going to tell you what to study.

10.1 Reliable sources

Not all sources are equal, and telling them apart saves an enormous amount of wasted time:

Source	Reliability	What for
MDN Web Docs	Very high	The reference for the web platform. Your first stop, always
Specifications (WHATWG, ECMA, W3C)	Maximum	When MDN is not enough or there is an odd edge case
Official documentation for the tool	High	Getting started and looking things up
Release notes and `CHANGELOG`s	High	Finding out about real changes without noise
Engineering blogs from known companies	Medium-high	Real experiences with context
Technical books	High, though they age	Depth and structure
Videos and tutorials	Variable	First contact; always verify
Forum answers	Variable and often out of date	Clues, never the last word
Unverified generated content	Low	A starting point, never the final answer

Three concrete habits worth more than any list of resources:

Go to MDN before a search engine. Half the time you look something up about JavaScript or the DOM, the canonical answer is there, up to date and with the compatibility table.
Read the release notes of what you use. Ten minutes when a new version of Node, your framework or your bundler comes out. It is the most efficient way there is to stay current, because it is information filtered by real relevance.
Check the date of everything you read. A 2016 answer about asynchrony in JavaScript may be correct or completely obsolete, and it does not say which.

10.2 Learning by building

It is still, by a wide margin, the most effective way. The progression that works:

Level	What to build	What it teaches
1	Rewrite something you already made with new technology	The technology, without the burden of designing the problem
2	A tool for yourself	Real requirements; you use it and see the flaws
3	Something somebody else uses	Edge cases, support, real feedback
4	Something with hard constraints	Scale, real time, offline, serious accessibility

Level 2 is the sweet spot and the most underrated. A tool solving a real problem of yours — a reader for something, an organizer for whatever, a dashboard of data you check often — has three enormous advantages: you know exactly what it should do, you actually use it (so the bugs show up), and the motivation depends on nobody.

And a size rule, already familiar from 11-01 but applied to learning: better a small project finished than a big one half done. Finishing teaches things that starting never does: deployment, documentation, edge cases, maintenance.

Reading other people's code and contributing

Reading other people's code is the skill that grows fastest and is practiced least. In real work you will read far more code than you write.

How to read a project you do not know, methodically:

#	Step	What you are looking for
1	README and documentation	What it is and how it runs
2	Folder structure	The mental map of whoever wrote it
3	Entry point (`main`, `index`)	Where everything begins
4	One complete flow, following the calls	How it connects
5	The tests	The best behavior documentation there is
6	The history of an odd file	Why it is that way (`git log -p`, `git blame`)

Step 5 is the shortcut almost nobody uses: if you want to know what a module does, read its tests before its code. They are written to explain behavior, not to implement it.

Contributing to open source projects teaches things no project of your own can:

Working with conventions you did not choose.
Going through a real code review by somebody who does not know you.
Understanding a large system before touching it.
Writing commit messages and PR descriptions for strangers.

How to start, in increasing order of difficulty:

Documentation. An error, a missing example, a translation. It is a real contribution and the barrier is minimal.
Reproducing issues. Taking a reported bug, confirming it and adding a minimal case. It is very useful and much appreciated.
Good first issues. Many projects label them for newcomers.
A small fix with a test. A bounded bug, with its regression test.
A feature, always after proposing it in an issue. Never open a large PR without having discussed it.

And some honest emotional preparation: your first contribution will probably get comments, requested changes, or even a rejection. That is normal and it is not personal. Whoever maintains a project is looking after its long-term coherence, not your afternoon. Apply the lesson from 11-06: criticism of the code is not criticism of you.

How to stay current without burning out

Web development has a reputation for changing too fast. It is half true, and the false half is what produces burnout.

What changes fast:

Fashionable libraries and their major versions.
Build tooling.
Specific patterns within a framework.
Opinions about the best way to do something.

What does not change:

The language (it adds, it almost never breaks).
The DOM and events.
HTTP, caching, security.
Accessibility.
How you test, how you debug, how you measure.
Designing a data model and a set of rules.
Knowing how to decide.

The proportion is the key to this whole section: the stable part is most of what you use daily, and it is exactly what this course has given you.

The five rules of information hygiene:

Rule	Detail
1 · Do not try to follow everything	It is impossible and it is the origin of burnout. Pick three or four areas
2 · Filter by permanence	Before studying something, ask: will this still be true in five years?
3 · Learn on demand	Study what you need for what you are doing. What is learned without use is forgotten in weeks
4 · One topic at a time	Depth in one is worth more than surface in five
5 · Rest without guilt	Nobody is up to date on everything. Nobody. Not even the people you most admire technically

A concrete sustainable rhythm, which you can copy:

Frequency	Activity	Time
Daily	Write code (even if it is 30 minutes)	30–60 min
Weekly	Read something technical calmly	1–2 h
Monthly	A new topic, applied to something real	4–8 h
Quarterly	Review where you are and adjust course	1 h
Yearly	A big leap (a technology or a specialization)	—

Consistency beats intensity, and that is not a platitude: an hour a day for a year is 365 hours and a habit; a twelve-hour weekend every two months is 72 hours and no habit.

About impostor syndrome, which will show up: it is practically universal in this profession, and it has a structural cause. You compare your inside — your doubts, your searches, what you do not know — with other people's outside — their talks, their articles, their confident answers. Nobody publishes their three hours hunting a semicolon. The antidote that works is not convincing yourself that you are good, but keeping a record of what you have done: a year ago you did not know what a promise was; today you have deployed a product with an idempotent synchronization queue. That is a fact, not an impression.

Why the fundamentals do not expire

It is worth closing the argument with the data from the course itself, because it is more convincing than any assertion.

In 10-06 you wrote the same screen four times: plain JavaScript, React, Vue and Angular. And the result was that domain/rules.js was identical in all four. The same forty lines. Everything that changed was the view.

That means, in measured rather than opinionated terms:

What survives a change of framework	What does not
The language	The specific template syntax
The data model and the rules	The name of the hook or the directive
Knowing how to structure in layers	This year's fashionable folder structure
Behavior tests	Tests coupled to the implementation
HTTP, caching, security	The request library of the moment
Accessibility	—
Performance and how to measure it	The exact thresholds
The judgment to decide	This year's opinions

And there is a second demonstration in your own project: your browser-independent domain/ can be imported as is into a Node server and run the same fifteen rules. Not because the design is clever, but because you respected a boundary throughout the whole module.

The practical conclusion is liberating: every hour invested in fundamentals pays off across your whole career; every hour invested in the fashionable tool pays off for as long as the fashion lasts. That does not mean ignoring the tools — you have to use them and you have to master one — but knowing where you are investing each time.

The six-month roadmap

Three profiles according to your real availability. Choose yours honestly, not the one you wish you could keep to: a plan broken from week three gets abandoned entirely.

Profile	Hours/week	Total over 6 months	Typical situation
A · Intensive	20–25 h	~550 h	Full-time or nearly
B · Sustained	10–12 h	~280 h	Work or study + evenings and weekends
C · Light	4–6 h	~130 h	Little time, but consistent

14.1 Profile A · Intensive (20–25 h/week)

Month	Main focus	Deliverable
1	TypeScript: JSDoc → full migration of your project	Your project in strict TS, no `any`
2	Chosen framework: fundamentals + rewriting your project	Your project in the framework, with tests
3	Framework: the full ecosystem (routing, state, forms, requests)	A new mid-sized project, deployed
4	Node.js: server, database, authentication	Your project's real backend
5	Full-stack: integrate, deploy, monitor	A complete product in production
6	Employability: portfolio, CV, interviews, basic algorithms	Portfolio and applications sent

14.2 Profile B · Sustained (10–12 h/week)

Month	Main focus	Deliverable
1	TypeScript with JSDoc over your domain	A typed, checked `domain/`
2	TypeScript complete + advanced Git	Project migrated; clean history
3	Framework: fundamentals, rewriting your project	Your project in the framework
4	Framework: ecosystem + tests	A small new project, deployed
5	Node.js: server + database	Your own working API
6	Integration and portfolio	A full-stack product + portfolio

14.3 Profile C · Light (4–6 h/week)

Month	Main focus	Deliverable
1	TypeScript with `// @ts-check` and JSDoc	A checked domain with no compilation
2	TypeScript: types for the data layer	Typed repository and API
3	Framework: fundamentals	One screen of your project migrated
4	Framework: a complete small application	A deployed application
5	Node.js: a minimal server using your domain	A working 3-route API
6	Consolidate and portfolio	An updated portfolio with 2 projects

gantt
    title 6-month roadmap — profile B (sustained, 10-12 h/week)
    dateFormat YYYY-MM-DD
    axisFormat %b

    section TypeScript
    JSDoc and @ts-check over the domain     :ts1, 2026-12-01, 30d
    Full migration + strict                 :ts2, after ts1, 30d
    section Tooling
    Advanced Git (rebase, bisect, reflog)   :git, after ts1, 21d
    section Framework
    Fundamentals rewriting the project      :fw1, after ts2, 30d
    Ecosystem, tests and deployment         :fw2, after fw1, 30d
    section Backend
    Node, Express and a database            :node, after fw2, 30d
    section Wrap-up
    Full-stack integration and portfolio    :fin, after node, 30d
    Web platform (1 topic/month, ongoing)   :plat, 2026-12-01, 180d

Notice the last bar: "web platform" runs across all six months. It is the continuous path from section 8, one topic a month in parallel. It does not compete with the rest because it is of a different nature.

How to use the plan:

Choose your profile honestly. B is the realistic one for most people.
Adjust the order to your goal. If you are job-hunting soon, move the framework up to month 1.
Review it every month. If a topic is costing you twice as long, adjust the plan, do not punish yourself.
One deliverable per month, no exceptions. With nothing finished, the month does not count. It is the same discipline as the milestones in 11-01.
Protect two fixed slots a week. Losing the rhythm is the number one cause of abandonment, well ahead of difficulty.

Career: portfolio, CV and interviews

I will start with the honest part, because too much material leaves it out: the entry-level market is competitive. There are far more people looking for a first job than there are junior positions, the processes are long, and you will get silences and rejections that do not reflect your worth. This is not discouragement: it is information so you interpret correctly what is going to happen and do not read it as a verdict about you.

What you can control, and where most people do not make the most of their margin:

15.1 The portfolio

Rule	Detail
Two or three projects, not ten	One big and finished — yours — and one or two small, well-finished ones
Genuinely finished	Deployed, with a README, with tests, defensible
With documented decisions	The ADRs from 11-06 are an enormous differentiator and almost nobody has them
With an accessible demo	A link that works, with sample data loaded
No tutorial clones	Another tutorial to-do list says nothing. Yours does, because it has rules, architecture and decisions of your own

15.2 The technical CV

Section	What to put
Header	Name, target role, city/remote, email, GitHub, LinkedIn
Summary	2–3 lines: what you can do and what you are looking for. No empty adjectives
Projects	Before education if you have no experience. With numbers and links
Technologies	Grouped and honest: separate what you have mastered from what you have seen
Experience	Even if it is from another sector: there are real transferable skills
Education	At the end if it is not the most relevant thing

The most frequent mistakes:

Listing 30 technologies. It communicates superficiality and exposes you to questions you cannot answer.
Putting levels with bars or percentages. "JavaScript 85 %" means nothing.
Adjectives with no evidence: "passionate", "proactive", "resilient".
Not including links. The GitHub and the demo are what actually gets looked at.
More than two pages with no experience to justify it.

15.3 Interviews

Stage	What they assess	How to prepare
Initial screen	Basic fit, communication, expectations	Have your two-minute pitch ready
Technical knowledge	Fundamentals: JavaScript, the DOM, asynchrony, HTTP	Review M3, M5 and M7. Know how to explain the event loop
Practical exercise	How you write and how you think	Practice out loud; explaining while you code is a separate skill
About your project	Judgment and depth	You already have it prepared (11-06)
Culture / team	How you work with others	Concrete examples of collaboration and of a resolved conflict

The topics most often asked at junior level, and for which this course has prepared you:

Topic	Module
`var`, `let`, `const`, scope and hoisting	03-04, 03-05
Closures	03-04
`this` and its rules	04-02
Prototypes and inheritance	05-01
Promises, `async/await` and the event loop	05-06, 05-07
Equality, coercion and falsy values	01-07
`map`, `filter`, `reduce`	04-04, 04-05
Event delegation and propagation	06-04
Requests, errors, CORS	07-02, 07-03
How would you test this	M8

About algorithm exercises. Some processes include them and others do not, and their weight varies enormously. If they appear in the listings that interest you, spend a couple of hours a week for a few weeks on the fundamentals: arrays, strings, maps and sets, two pointers, and being able to reason about complexity. It is not the first thing to spend time on if it is not asked for, but you do not want to discover it on interview day either.

And the advice that most changes the outcome of a technical interview: think out loud. The interviewer wants to see how you reason, not just whether you get there. Say what you are considering, the alternatives you are discarding and why. A half-finished exercise with excellent reasoning scores better than a correct solution that comes out of nowhere — and if you get stuck, saying "I do not know this, but I would approach it like this" is a perfectly valid answer.

The first job and learning on the job

16.1 How to look for it

Route	Effectiveness	Note
Contacts and referrals	The highest	Local meetups, communities, former colleagues
Job boards	Medium	High volume, high competition
Applying directly to companies	Medium-high	Personalized, to companies that genuinely interest you
Specialist recruiters	Medium	Useful when they reach you; little control
Internships and traineeships	High	The classic entry route and perfectly valid

A concrete, road-tested recommendation: go to technical meetups in your city. Not to hand out CVs — that works badly — but to meet people and talk about what you are working on. A very high proportion of first jobs comes through somebody who knows you, not through a form.

And an important calibration: listings describe an ideal, not a requirement. If you meet a reasonable part of what they ask for, apply. Ruling yourself out before they rule you out is the most expensive and most common mistake.

16.2 The first few months

Month	What to expect	What to do
1	The feeling of understanding nothing	It is normal and universal. Ask a lot; take notes
2–3	First small tasks	Finish them properly. Reliability is worth more than speed
4–6	You start moving on your own	Volunteer for what nobody wants: that is where you learn
6–12	You genuinely contribute	Start proposing, not just executing

Five things that greatly accelerate learning on the job:

Ask early, with context. "I tried A and B, I expected X, I get Y, where should I look?" is a question that bothers nobody. Being blocked for three days in silence does.
Read the repository's code even when it is not your task. It is the fastest way to understand the system and the conventions.
Ask for reviews and ask for demanding ones. "What would you have done differently?" is the sentence that will make you grow the most.
Review other people's code. It teaches a great deal, even if at first you feel you have no authority to do it. Asking a question in a review is already contributing.
Write down what you learn. A document of your own with "things about this system". In six months it will be your most valuable asset, and in twelve, the one used by whoever comes after you.

And a warning about comparisons. You are going to work with people who know far more than you. That is not a sign that you are not good enough: it is exactly why that is a good place to be. An environment where you are the person who knows the most is an environment where you do not learn.

Common Mistakes and Tips

Starting four paths at once. TypeScript, React, Node and Docker in parallel produces three months of the feeling of progress and zero depth in anything. One at a time, with one deliverable per month.

Jumping from framework to framework every two months. The value is in the depth, and depth only arrives past the point where the novelty ends and the hard problems begin. Pick one and stay.

Learning by accumulation instead of by use. Watching twenty hours of video without writing code produces the feeling of learning and very little actual learning. The rule: for every hour of consumption, at least one of building.

Waiting until you "know enough" to look for a job. That moment never arrives because the bar rises with you. With one finished, defensible project you already have more than plenty of people who are applying.

Confusing the noise with the profession. Arguments about which framework is better are entertainment. The real work is understanding problems, modeling them, and delivering something that works and can be maintained.

Ruling yourself out before they rule you out. Listings describe ideals. If you meet a reasonable part, apply: the decision is not yours to make.

Comparing yourself to public profiles. You are comparing your inside with other people's outside. Nobody publishes their three hours hunting a semicolon.

Giving up after losing your rhythm for two weeks. Losing the rhythm is normal. What sinks a plan is not the pause, but turning the pause into abandonment. Come back with a small session, without catching anything up.

Tip · Write down what you learn, even if nobody publishes it. Explaining forces you to understand properly, and it exposes the gaps that reading hides. And if you publish it too, it is portfolio.

Tip · Finish things, even small ones. Finishing teaches what starting never does: deployment, documentation, edge cases and maintenance. And it is the competency that sets you apart the most.

Tip · Keep your progress curve. A file with what you knew six months ago. It is the most effective antidote to impostor syndrome, because it is a fact and not an impression.

Tip · Teach somebody. Explaining to a beginner consolidates more than rereading. And right now you can: there is somebody where you were in Module 1.

Tip · Always have a project of your own in progress. Even a small, slow one. It is where you experiment without consequences, where you keep your curiosity, and where almost everything you later use at work is born.

Exercises

The last exercises of the course are not about code: they are about direction. Give them real time, because their result is what you will be doing for the next six months.

Exercise 1 — The stocktake and the plan.

Fill in your competency inventory: go through the table in section 1 and mark each row with "I have mastered it", "I have done it", "I have seen it". Be honest: the table is for you.
From the list in section 2, choose the three uncovered areas that matter most for your goal, and write down why for each.
Choose your commitment profile (A, B or C) by counting the real hours you have available this week, not the ones you would like to have.
Write your six-month roadmap with the template from section 14, adapted to your goal: month, focus and concrete deliverable. One deliverable per month, no exceptions.
Draw your plan as a Mermaid Gantt chart, including the continuous web-platform bar.
Block the slots in your calendar — two fixed ones a week — and set a monthly review reminder.
Write your six-month goal in one sentence, along the lines of "in six months I want to be able to build and deploy a full-stack application with TypeScript and apply for junior front-end positions".

Exercise 2 — The first TypeScript step, today.

Do not let the plan stay on paper: the first step is taken now and it costs an afternoon.

Add // @ts-check to the most important file in your domain.
Document all its public functions with JSDoc: parameters, return types, optionals and null.
Fix everything the editor underlines. Note how many real problems it found — there will be one you did not expect.
Create a jsconfig.json with checkJs and strict for all of src/, and note how many errors appear.
Write the equivalent of the types.ts file from section 4.4 for your domain: literal unions for your closed sets, readonly where appropriate, and the Record that guarantees your transition matrix covers every status.
Document in docs/decisions.md what it gave you and what it cost you. It is the information you will use to decide whether to migrate fully.

Exercise 3 — Direction and portfolio.

Choose your framework with the one-hour procedure from section 6.2: fifty real listings in your market, counted. Note the numbers and the conclusion.
Choose the monthly web-platform topic for the next three months (accessibility, security, modern CSS, performance…) and what you will do with each on your project.
Update your portfolio with everything from 11-06: pinned repository, profile README, CV with concrete numbers and links.
Write your two-minute pitch: who you are, what you can do, what you have built and what you are looking for. Rehearse it out loud.
Identify three companies you would like to work at and note, for each, what they ask for that you do not have yet. That adjusts your roadmap with real data.
Teach somebody something: write an explanation of a concept you have mastered — closures, the event loop, why the domain must not know about the browser — aimed at somebody where you were in Module 1. Publish it or share it.
Start the next project, however small. The best way to consolidate what you have learned is to use it before it goes cold.

Solutions

There are no correct solutions for these exercises: they are your decisions. These are the criteria you can use to judge whether your plan is a good one.

Criteria for a good six-month plan

#	Criterion	Sign it is failing
1	One main direction	Four technologies in month 1
2	Realistic hours	Profile A with 5 free hours a week
3	One concrete deliverable per month	"Learn TypeScript" instead of "project migrated to strict TS"
4	Verifiable deliverables	You cannot tell whether it is done or not
5	It builds on what you already have	It starts a new project from scratch instead of using yours
6	It leaves slack	Six months filled to 100 %, with no headroom
7	It aims at a stated goal	You do not know what the plan is for
8	It has a monthly review	It is written once and never looked at again

Rubric for the plan (18 points)

Dimension	0	1	2	3
Honesty of the inventory	Inflated or empty	Approximate	Realistic	With evidence per competency
Choice of direction	Undecided	Chosen	Justified	With data from your market
Realism of the hours	Fantasy	Optimistic	Realistic	Measured against a real week
Deliverables	Vague	Concrete	Verifiable	Each one usable in the portfolio
Continuity	No slots	Slots	Protected slots	Plus a scheduled monthly review
Connection to the goal	None	Implicit	Explicit	With three companies and their gaps identified

Threshold: 12/18. And one condition that cannot be traded away: exercise 2 has to be done, not planned. A plan with no first step taken the same day is a wish list.

The course's final self-assessment:

Question	Yes / No
Do I have a product of my own, finished, deployed and defensible?
Can I explain why I made its main decisions?
Do I know what this course does not cover and which of those gaps matter to me?
Have I chosen one main direction for the next six months?
Have I already taken the first step, today, not "next week"?
Do I have two weekly slots protected in my calendar?
Do I know where to look when I do not know something, and how to tell a reliable source?
Do I understand that the bar rises with me and that this is progress, not failure?

Conclusion

This is where the course ends, so this closing does not set up a next lesson: it takes stock and hands you back the controls.

You have the real inventory of what you know, competency by competency and module by module: setting up an environment and reading an error without freezing; expressing rules with conditionals and handling errors distinguishing the expected from the exceptional; breaking things into functions, using closures and solving recursive structures; modeling entities and transforming collections; designing classes with real encapsulation, organizing into modules and mastering asynchrony; building framework-free interfaces with events, delegation and accessible forms; persisting, talking to an API, using WebSockets and turning a site into a PWA; debugging methodically and testing at three levels; measuring before optimizing and setting a budget; knowing four frameworks and, above all, choosing with judgment; and planning, building, synchronizing, testing, deploying and defending a complete product. With the cross-cutting competencies no syllabus lists: turning a problem into a model and a set of rules, deciding and being able to defend it, measuring before opining, debugging methodically, writing maintainable code and — the one that sets you apart the most — finishing things.

And you have, with the same honesty, what this course does not cover: static typing, the backend, a framework properly, modern CSS, databases, algorithms, security in depth, architecture at scale, DevOps, mobile, and the things that are only learned by working with other people and with code somebody wrote four years ago. Knowing your own gaps is worth as much as knowing your own capabilities, and not confusing "I have not mastered it yet" with "I am not good enough" is a professional skill in itself.

You have the map of the paths with the rule that governs it: one main direction for the next six months, just one, because the others will still be there. TypeScript as the cheapest to start — today, with // @ts-check and JSDoc over your own domain, compiling nothing — and the one that multiplies the value of everything else, with the gradual migration starting from the domain and with those four things you get for free: literal unions that make it impossible to write an invented status, readonly that expresses encapsulation in the type, a Record that forces you to cover every transition, and your repository contract checked by the compiler. Node.js as the path that closes the system, with the concrete reward of importing your own domain/ into a server and running the same fifteen rules where the user cannot bypass them. A framework in depth, with the clear difference between the hundred hours that give a working level and the five hundred that give real value, chosen with an hour of counting listings in your market rather than global trends, and starting by rewriting your own project because the domain is already done. And the two continuous paths: tooling — with advanced Git as the best investment per hour in the whole table — and the web platform, one topic a month, which never expires.

You know how you keep learning when there is no course: MDN before a search engine, release notes as the most efficient way to stay current, checking the date on everything you read, and the building progression whose sweet spot is a tool for yourself, because you know what it should do, you actually use it and the motivation depends on nobody. You know how to read other people's code starting with the tests, and how to contribute starting with documentation, with the emotional preparation that the first comments will come and are not personal.

You know how to stay current without burning out, distinguishing what changes fast — libraries, tools, opinions — from what does not change — the language, the DOM, HTTP, accessibility, how you test, how you measure, how you decide — with the five rules of information hygiene and a sustainable rhythm where consistency beats intensity. And you know that impostor syndrome has a structural cause — comparing your inside with other people's outside — and an antidote that is a fact rather than a pep talk: keeping a record of what you have done.

You have the argument for why the fundamentals do not expire, and not as an opinion but as a measurement from this very course: domain/rules.js was identical in plain JavaScript, React, Vue and Angular. The same forty lines. Everything that changed was the view. Every hour invested in fundamentals pays off across your whole career.

You have a six-month roadmap in three commitment profiles, with a mandatory deliverable per month and two protected weekly slots, because losing the rhythm sinks more plans than difficulty does. And you have the career part with its honesty up front: the entry-level market is competitive and the silences are not a verdict about you; what you control is a portfolio of two or three finished, defensible projects — with ADRs, which almost nobody has — a CV with numbers and links instead of adjectives and percentage bars, and interviews where thinking out loud changes the outcome more than knowing the answer. And the first months at work, where understanding nothing is universal, where asking with context bothers nobody, and where working with people who know more than you is not a threat: it is exactly why that is a good place to be.

And now the real closing.

The first line of code in this course was console.log('Hello, Taller Nómada');. One function, one string and a message in a console. That day you did not know what a variable was, and Marta, Iván and Lucía's board was six tasks and forty-eight hours that did not even fit into an object because objects came three modules later. Since then those six tasks have been conditionals, loops, functions, arrays, classes, promises, DOM nodes, API requests, tests, measured milliseconds and four versions of the same screen. They have been the thread holding every new concept together, and they are still there, intact: 48 hours, 45 open, one overdue, weighted effort 124.

But Nómada Tasks stopped being your project six lessons ago. In Module 11 the guided example stepped aside and you built your own: your product, your model, your rules, your decisions, your bugs and your regression tests. Taller Nómada stayed where it had to stay, as a reference to compare against, and what is deployed today over HTTPS carries your name and not its own.

That is everything this course could give you: a language, a method and a finished product that proves you know how to use them. What remains cannot be written by anybody else, because there is no longer a next lesson to link to or a module starting tomorrow. There is a roadmap you wrote yourself, an open editor, and the only question that matters from here on:

Next Steps: TypeScript, Node.js and Your Career

Contents