Two tracks at once: land a tech job now for steady income, and build your own company and services on top of it. Master technology and business together, go from $0 to $100K+, and track all of it here, roadmaps, thoughts, learnings, a wishlist, and certs, in one place.
Get hired in an automation, backend, or data role, or take paid freelance gigs, using the skills you already hold. It covers your costs, buys runway, and pays you to keep leveling up. Target: steady monthly income in 60–90 days.
Build the high-ticket services company on nights and weekends with the roadmaps in this manual, automation and agents first, security and cloud as premium layers. This is the ceiling: recurring revenue and leverage.
Phase-based paths in learning order, each with sub-concepts, resources, and checkable progress. Your focus domains, plus the craft and career pages.
Has AI made coding obsolete? What the real data says, what to focus on now, and which kind of engineer to be.
Half true. The typing is being automated. The engineering is not, and demand for it is going up, not down.
AI now writes a lot of the boilerplate, so you spend less time on raw syntax. But you do not stop being an engineer. Every official source points the same way: more demand for people who build software, and it moves higher up the stack.
What changed is where your value sits. AI drafts; you judge. The 2025 Stack Overflow survey of tens of thousands of developers makes it concrete:
Read that carefully. AI writing code did not delete the work, it relocated it. The scarce, paid skill is now catching the "almost right", understanding the whole system, and being accountable for correctness and security. In the same survey, 61% of developers said they want to fully understand their code, and they are right to.
If AI does more of the typing, invest where it cannot be trusted to act alone. In rough priority for you:
All three, as one person. That composite is exactly where the market is moving, and you are already most of the way there.
You wanted to be a software engineer. Keep that. Software engineering is the foundation that makes everything else trustworthy: without it you cannot review what AI writes or design a system that holds together. But do not stop there, because "produce code to spec" is the part AI compresses. Layer up:
That is a rarer and more valuable profile than any one of the three alone, and it is a straight extension of the Data & Automation Engineer you already are.
Everything above converges on the same next step: build one real AI agent. It is the frontier skill, it rides your automation strength, and it is the profile every source on this page is pointing at.
Official and primary sources, so you can check every number yourself.
Never touched code? Start here. Understand what a computer is, how the internet works and how programmers think, before you write a single line.
Every course in this academy stands on these ideas. People who skip them can copy code but cannot fix it. People who learn them pick up any new tool quickly.
Know the parts of a computer and what each one does, in plain words.
Open Task Manager (Ctrl+Shift+Esc on Windows) or Activity Monitor on Mac. Find the three programs using the most memory and write what each one is.
Get comfortable with the tools every developer uses before any code appears.
Make a folder called code, open it in VS Code, create index.html with the word Hello, save it and open it in the browser. Then list the folder from the terminal.
Understand what really happens between your phone and a website, and how to stay safe.
Press F12 on any website, open the Network tab and reload. Count the requests and find the biggest file the page downloaded.
Learn the handful of ideas that every program in every language is built from.
Solve the first five levels of Logic Lab. Level five needs a function, so find the repeating pattern and give it a name.
Meet the ideas first-year computer science tests you on, explained without scary words.
Write the exact steps to make breakfast so someone who never did it could follow them. Then ask an AI assistant to find a missing step and check if it is right.
Know which jobs exist, what their days look like, and which one to try first.
Pick the two jobs that sound most like you. Watch a day-in-the-life video of a real person doing each one and write one thing that surprised you.
Build the habits that decide whether you finish a course or quit halfway.
Solve challenge 1 in Code Lab. It takes about a minute, and you will have written and run real code.
Longer, plain explanations of the ideas in this course, for when a lesson needs more.
A computer is just a machine that follows instructions very fast. It has two halves: the physical parts (hardware) and the instructions (software).
Hardware is anything you can touch. The CPU is the brain that does the calculations. RAM is short-term memory: fast, but wiped when you turn the machine off. Storage (SSD or hard drive) is long-term memory that keeps your files. The screen, keyboard, and mouse are hardware too.
Think of a kitchen: the CPU is the cook, RAM is the counter space you're working on right now, and storage is the pantry.
Software is the set of instructions that tells the hardware what to do. You can't touch it. An operating system (Windows, macOS, Android) is the software that runs everything else. Apps (a browser, WhatsApp, a game) are software built to do one job.
Hardware is the body; software is the thoughts telling it what to do.
Programming is writing the exact, step-by-step instructions a computer follows. The computer is fast but literal: it does exactly what you say, nothing more.
Almost all code is built from four simple ideas. Variables are labeled boxes that hold a value (a name, a number). Sequence is doing steps in order, top to bottom. Conditions (if / else) make decisions: "if the user is logged in, show the dashboard, else show login." Loops repeat a step many times so you don't write it a thousand times.
That's it. Every app, no matter how big, is those four ideas stacked up.
A programming language lets you write instructions in something closer to human words, which the computer then translates into its own 1s and 0s. Python reads almost like English and is great to start with. JavaScript runs in every web browser. There are many, but the logic above is the same in all of them, so learning one makes the next far easier.
Beginners think they need to memorize a language. You don't. You need to think in steps and conditions. Once you can break a problem into "first do this, then if that, repeat this," writing it in any language is just looking up the exact words. Learn the thinking, not the syntax.
The internet is the roads. The web is one kind of traffic on those roads. And "website" vs "web app" trips everyone up, here's the difference.
The internet is the global network of cables and computers connected together, the roads. The web is the system of pages and links you browse on top of it. Email and video calls also use the internet but are not "the web." So the web is one thing that runs on the internet, not the same as it.
A web page is a single page. A website is a collection of pages about one thing, usually to read (a blog, a restaurant's site, a news site). A web app is a website you use and interact with, like a tool: Gmail, Google Docs, Netflix, or this academy. The line is simple: a website you mostly read; a web app you do things in.
The frontend is everything you see and click in the browser: buttons, colors, layout. The backend is the engine on a server you never see: it stores data, checks your password, and does the heavy work. When you log in, the frontend takes your password and the backend checks it. Most apps need both.
A server is just another computer, always on, that other computers ask for things. When you open a website, your browser (the client) asks a server for the page, and the server sends it back. "The cloud" is mostly just someone else's servers you rent instead of owning.
You don't need much to start. Here are the words for the tools every developer uses daily.
Code lives in files, organized in folders. A file's extension (the bit after the dot) says what kind it is: .html for a web page, .css for styling, .js for JavaScript, .py for Python. The computer uses it to know how to read the file.
You write code in a code editor. The most popular is VS Code, and it's free. An IDE (Integrated Development Environment) is a code editor with extra tools built in: running code, debugging, autocomplete. For most beginners VS Code is all you need, and people use "editor" and "IDE" loosely.
The terminal is a text window where you type commands instead of clicking. It looks intimidating but you only need a handful of commands. It's how you run programs, install tools, and use Git. Every developer lives in it a little.
Git saves snapshots of your code as you work, like save points in a game, so you can go back if you break something. GitHub is a website that stores those snapshots online and lets people work together. You'll learn it early; past your first project it's non-negotiable.
This is the part universities test you on in first year, and the part almost nobody arrives knowing. Learn it now and your degree gets dramatically easier.
A computer has no idea what a letter, a photo or a song is. It only knows on and off, which we write as 1 and 0. That is binary.
Think of a row of light switches. One switch gives you 2 options. Two switches give 4. Eight switches give 256, and eight switches is called a byte. Every letter you type is a number: the letter A is 65. Every colour is three numbers. Every song is thousands of numbers per second.
So when someone says "it is all ones and zeros", they mean it literally. Everything above that is humans agreeing on what the numbers mean.
The CPU does one boring thing, billions of times a second: fetch an instruction, work out what it means, do it, repeat. That is called the fetch-decode-execute cycle and it is the entire secret of computing.
Each instruction is tiny. "Add these two numbers." "Put this number over there." "If this is zero, jump to that instruction." Nothing more clever than that. Fortnite, Instagram and the software flying an aeroplane are all just enormous piles of those tiny steps.
That is genuinely encouraging: the computer is not smarter than you. It is just much, much faster and never gets bored.
An algorithm is a set of steps that solves a problem, guaranteed to finish. A recipe is an algorithm. Long division is an algorithm you already learned at school.
Here is one you use without noticing. Looking up "Morales" in a phone book: you do not start at page 1. You open the middle, see you are too far, open the middle of what is left, and repeat. That is binary search, and it finds one name in a million in about 20 steps instead of a million.
Computer science is largely the study of finding steps like that: the ones that get the answer without doing the stupid amount of work.
Two programs can do the same job, one in a second and one in a week. The difference is how the work grows as the data grows.
Checking every name one by one in a list of 1,000 takes up to 1,000 looks. Double the list and it doubles to 2,000. Binary search on the same list takes about 10 looks, and doubling the list adds one look. That gap is why your phone can search millions of photos instantly.
You will meet this in university as "Big O notation". It sounds terrifying and it means exactly what you just read.
Where you put things decides how fast you can find them. A messy bedroom and an organised one hold the same objects, but finding a sock takes very different amounts of time.
List (array): things in a row, numbered. Great for going through everything in order. Dictionary (map): things with labels, like a real dictionary. Instantly find "cat" without reading every word. Stack: like a pile of plates, last in, first out. That is exactly how the undo button works. Queue: like a line at the bank, first in, first out.
Choosing the right one is half of writing fast software.
You drive a car without knowing how the engine burns petrol. The steering wheel hides the complexity and gives you a simple handle. That is abstraction.
Software is layers of this. Someone wrote the tiny CPU instructions so someone else could write an operating system, so someone else could write a language, so you can write one line that puts a button on a screen. You stand on about seven layers of other people's work every time you code.
Practical meaning: you do not need to understand everything to build something. You need to understand the layer you are on, and trust the rest until you need it.
This is the single most valuable skill in this entire academy, and it needs no computer.
"Build Instagram" is impossible. "Show one photo on a page" is a Tuesday afternoon. Then "show a list of photos". Then "let someone upload one". Then "add a like button". Each one is small enough to actually start.
Every professional developer does exactly this, every day. When you feel stuck, you are almost never facing a hard problem. You are facing a big one you have not cut up yet.
Most people choose a career from a job title they half understand. Here is what the days actually look like, so you choose with your eyes open.
First-year computer science has a brutal drop-out rate almost everywhere. It is not because the students are not clever. It is because half of them meet all of this for the first time in week one, while the other half already knew it.
Pass it with 80% or more to earn the certificate for this course.
HTML tags are like LEGO bricks. Each one has a job. You do not need to memorize them, you need to know which brick to grab. Search or filter, and copy the example.
Not tools, ideas. If you understand these, every framework and language after this becomes easy. Explained simply, with real examples.
Imagine ordering a pizza. You call the shop, they make it, they deliver it. The web works the same way.
google.com is like dialing the pizza shop's number. But computers use numbers, not names, so DNS is the phone book that turns "google.com" into an address like 142.250.0.1.Every website on Earth is built from these three. That is not an exaggeration. Even Facebook is these three underneath.
HTML decides what things are. This is a heading. This is a paragraph. This is a button. This is an image. It is the skeleton of the house: walls, doors, windows. Without it there is no page at all.
If you only wrote HTML, you would get a plain, ugly, black-and-white page, but it would work. Like a house with no paint and no furniture. It still stands.
<h1>My Pizza Shop</h1> <p>The best pizza in Santa Cruz.</p> <button>Order now</button>
CSS decides how things look. Colors, sizes, spacing, fonts, where things sit on the screen. Same house, but now painted, furnished, and arranged nicely.
The magic part: you can change the whole look of a site by changing only CSS, without touching a single word of the HTML. Like repainting your room without rebuilding the walls.
h1 { color: purple; font-size: 40px; } button { background: purple; border-radius: 999px; }
JavaScript decides what happens. Click a button and a menu opens. Type in a box and it checks your email. Data loads without refreshing the page. It is the electricity and plumbing that make the house actually work.
HTML and CSS cannot make decisions. JavaScript can: "if the user clicked this, then do that."
button.addEventListener('click', () => { alert('Your pizza is on the way!'); });
These come up on literally every project. Understand them once and you are set.
When the browser reads your HTML, it builds a tree in memory, like a family tree. The body is the parent, a div inside it is the child, the text inside that is the grandchild. That tree is called the DOM.
Why you care: JavaScript changes the page by grabbing branches of this tree. "Find the button, change its color." Without the DOM there would be nothing to grab.
Every single thing on a web page is a rectangle, even round buttons (they are boxes with rounded corners). Each box has four layers, like a gift: the content (the gift), padding (bubble wrap inside), border (the box itself), and margin (space between this box and the next).
90% of "why is my layout broken" is a padding or margin misunderstanding. Learn this early and save months.
Your site must look good on a tiny phone and a huge monitor. Instead of building two sites, you build one that stretches, like water taking the shape of its glass.
You do it with flexible widths (percentages instead of fixed pixels) and media queries, which say "when the screen is smaller than 600px, stack these side-by-side boxes on top of each other instead." Always design the phone version first, it is the hardest and most common.
Semantic means using the tag that describes the meaning: <nav> for a menu, <button> for a button, not a <div> for everything.
Why: a blind person uses a screen reader that reads the page out loud. It can say "navigation, 5 links" only if you used the right tags. Google reads it the same way to rank you. Doing it right helps humans and your search ranking at the same time.
An event is something that happens: a click, a key press, the page finishing loading, a form being submitted. Your JavaScript "listens" for these, like a dog waiting for the doorbell.
Everything interactive is: listen for an event, then do something. That is the entire pattern.
An API is a waiter. You do not walk into the restaurant kitchen; you tell the waiter what you want and they bring it. Your site asks another service ("give me today's weather") and gets data back.
That data usually comes as JSON, which is just text organized in labeled boxes: {"city": "Santa Cruz", "temp": 28}. Easy for computers and humans to read.
Git takes snapshots of your code, like save points in a video game. Break something? Load the last save. Working with a friend? You each work on your own copy and merge them together.
Nobody works professionally without it. Learn the five commands you actually use: add, commit, push, pull, branch.
Your site on your laptop is a diary in your drawer, nobody can read it. Hosting is putting those files on an always-on computer. A domain (mysite.com) is the easy-to-remember name that points there.
Today this is free and takes minutes: push to GitHub, connect Vercel or Netlify, and you have a real link you can send to anyone.
Right-click any website and choose "Inspect." You can now see and change the HTML and CSS of any site live, see errors in the console, and watch the network requests.
This is the single most underused beginner tool. You learn by taking real sites apart. It is free and it is on every site in the world.
Performance: people leave if a page takes more than about 3 seconds. The usual culprit is huge images. Shrink them and you have solved most of it.
Security: never trust what a user types, always check it on the server too. Never put passwords or secret keys in your frontend code, anyone can read it with Inspect.
HTML, CSS and JavaScript are tools, not the only tools. You can also build websites with Wix, WordPress, Shopify and others. Here is the honest comparison and when to use each.
You can build it brick by brick (code), assemble a prefab kit (WordPress), or rent a furnished apartment (Wix). None is "wrong." They fit different situations.
You build everything yourself. Total freedom: any design, any feature, no limits and no monthly fee for the tool itself.
Use it when: you want a career in tech, you are building a real app (login, data, dashboards), you need something custom that no template can do, or performance matters a lot.
Skip it when: a local bakery needs 4 pages by Friday. Coding that from scratch wastes everyone's money.
A ready-made system you install, then add themes (looks) and plugins (features). It runs roughly 4 out of every 10 websites on Earth. Huge community, cheap, and the client can edit their own text.
Use it when: blogs, news sites, business sites, anything content-heavy, and especially when the client wants to update it themselves without calling you.
Watch out: it gets slow and messy if you stack 30 plugins, and it needs updates and security care.
Drag and drop, no code at all. You pick a template, move things with the mouse, and publish. Hosting, security and updates are handled for you, for a monthly fee.
Use it when: a small business or a personal portfolio needs to be online fast and cheap, and nobody technical will maintain it.
Watch out: you are renting. You cannot easily move your site somewhere else later, and you hit walls the moment you want something unusual.
Visual builders that generate real, clean code underneath. You design with your mouse but get near-code-level control, animations and responsive design.
Use it when: the design must be beautiful and custom, but you do not want to hand-code every pixel. Very popular for agency and startup marketing sites.
Watch out: a real learning curve, and still a monthly cost.
Built for one job: selling products online. Payments, inventory, shipping and checkout all work out of the box, which is the hardest part of e-commerce to build yourself.
Use it when: the client sells physical or digital products. Do not rebuild a shopping cart from scratch, it is a solved problem.
Describe your site and it generates one in minutes. Great for a quick landing page or testing an idea before investing.
Use it when: you need something online today to validate an idea.
Watch out: least control, and often generic. Fine as a start, not as a foundation for a serious product.
They pick at 17, based on a job title, a salary they read somewhere, and what a relative told them. Then a third of them change course or drop out, having lost a year and a lot of money. This is a fixable problem, and it is fixed before university, not during it.
Two parts. The talk gets their attention. The platform is what actually changes the outcome, because it keeps working after I leave the building.
A working engineer, not a recruiter, explaining the tech field honestly: what the jobs really are, which need heavy maths and which do not, what a normal day looks like, what it pays, and what nobody tells them. Then every student takes a short quiz that suggests a direction based on how they actually answered.
Students leave with: a suggested direction, a free account, and the first course already open.
The Foundations course: what a computer really is, how the internet works, how computers think, the jobs that exist, and how to arrive ready. Plus Logic Lab, which teaches programming logic as a puzzle with no code at all, and Code Lab, where they write real code in the browser and it checks their work automatically.
You get: students who keep going after the assembly ends, which is the part most careers talks never achieve.
Eduardo Shande. Data and automation engineer, Santa Cruz, Bolivia. Three years building software, data pipelines and AI automation for clients in Bolivia and the United States.
Self-taught, no computer science degree. That matters here, because it means the advice students get is about what actually works rather than what a syllabus says should work. It also means the honest parts get said out loud: which jobs are oversold, which are quietly well paid, when a degree is worth it and when it is not.
Nobody builds anything with one tool. They build with a chain of them, where each one hands its work to the next. Beginners drown because they meet the tools one at a time and never see the chain. Here is the chain first, then the tools.
There are thousands of developer tools and it is genuinely overwhelming. You need about eight, they are all free, and the list has barely changed in a decade.
This is the part nobody explains. A tool on its own is trivia. A tool passing its output to the next tool is how work actually happens. Each chain below is a real workflow you can copy today.
The first chain everyone should complete, end to end, in one afternoon. Do this once and half of tech stops being mysterious.
The magic moment: once GitHub and Vercel are connected, you type git push and your live site updates by itself in about twenty seconds. That is the whole modern workflow, and it is free.
The chain behind every app that has accounts, saves data, or does anything a page alone cannot.
Worth knowing: FastAPI generates an interactive test page for free, so you can skip Postman until you need to save collections. That is the general rule with tools: use the one already in the box first.
The chain that earns money soonest, because a small business will pay for ten hours a week back and will not care how you did it.
The trick: you are not selling n8n. You are selling "the order confirmations send themselves now." Never lead with the tool, always lead with the hours.
Least code of any chain here, and it is a real job in almost every company.
Where beginners stop too early: at the chart. The chart is not the deliverable. The sentence under it is.
Notice that the model is one box in the middle. Everything around it is ordinary engineering, which is exactly why the fundamentals matter more now, not less.
Never skip the second box. The API key lives on your server, never in the browser. A key in frontend code is visible to everyone and people will spend your money with it.
Deciding what it should look like before you write CSS saves more time than any other habit on this page.
Free for students: Figma's free tier is generous, and paper is cheaper. Most professionals still start on paper.
Grouped by the job it does. You do not need most of these yet. The point is that when someone says the name, you know which box on a chain it lives in.
The most common way to waste a month is to learn a tool you have no use for yet. You will forget it, because nothing hurt enough to make it stick.
Every developer you admire got unstuck by asking somebody. Ask here when you are stuck, and answer when you are not. Explaining something badly and then better is how you find out you actually understood it.
Type the question you were about to send. This will tell you exactly what is missing from it, rewrite it into one that can actually be answered, and turn it into a prompt worth giving an AI. Learning to ask well is the single skill that speeds up everything else you learn.
This is not about being polite. It is that the act of writing a proper question solves the problem surprisingly often, before anybody reads it.
It has a name: rubber duck debugging. Programmers keep a rubber duck on the desk and explain the problem to it out loud. Somewhere around sentence three they say "oh" and fix it themselves. Nothing about the duck helped. Being forced to say it in order did.
AI will answer a lazy question. That is exactly the danger. It hands you code that works, you paste it, and you have learned nothing and cannot fix it when it breaks next week.
The default reply to "fix my code" is a wall of code. You paste it, it works, and you are no better than you were an hour ago. Then it breaks and you are stuck again with a file you no longer recognise.
Always say: "explain what is causing this before showing me any code." That single sentence turns a vending machine into a tutor.
The five ingredients above work on AI too, for the same reason. "It doesn't work" gets a guess. Your goal, your code, your error and what you tried gets an actual diagnosis.
The prompt this page builds already has them arranged in that order, which is why it is worth copying rather than typing "help" and hoping.
Left alone, AI will happily rewrite your whole file in a style you did not choose, using things you have not learned. Now you cannot read your own project.
Say "show me only the lines that change." You want a repair, not a replacement.
This is the rule that matters most, so make it a hard one for yourself. If you cannot say out loud what a line does, you are not allowed to use it yet.
Ask instead: "what does line 3 do, and why is it needed?" Keep asking until you could rewrite it from memory. That is the difference between a student who gets good in a year and one who is still stuck in three.
AI does not know when it is guessing. It will invent a function that does not exist, name an option that was removed years ago, and describe it all in the same calm, certain voice it uses when it is right.
So verify: run it, and check anything unfamiliar against the real documentation. When it names something you have never heard of, that is exactly the moment to look it up rather than trust it.
The most underused prompt there is: "ask me three questions about this code to check whether I actually understood it."
You will find out in about a minute whether you learned the thing or just watched it happen. Uncomfortable, and worth far more than another answer.
These numbers are yours and they never reset. Show this page to a parent, a teacher, or one day an employer. It is proof you did the work, and proof is worth more than a promise.
Two labs, in this order. Logic Lab teaches you to think in steps with no code at all: sequencing, loops, functions and debugging, as a puzzle. It is the part everyone skips and then struggles with forever. Code Lab gives you a real editor and a live preview to write actual HTML, CSS and JavaScript.
Google, Meta, Amazon, Microsoft, IBM and Cisco give away world-class training. Not trial versions, not teasers. Real courses, many with a certificate, all $0. Here is the shortlist, sorted by topic, so you never pay for something that was free.
The most common way to waste a year in tech is to collect free courses like stickers and finish none of them.
Imagine a kid who owns 40 books and has read none. That is what a bookmark folder full of courses is. Owning is not learning.
Do one of these before anything else. They teach you how to think, which is the part that never expires.
The people who wrote the rules of the web also wrote the best free courses about it. Use the source.
All three giants train you free, because they want you fluent in their platform. That is your gain.
Automation is the shortest path from "learning" to "someone pays me", because you can save a small business ten hours a week with a weekend of work.
Four blocks, in this order: the language, the DOM, events, libraries. Skip a block and everything after it feels like magic you cannot fix. Do them in order and it feels obvious.
HTML is the body. CSS is the clothes. JavaScript is the brain and the muscles. It is the only one of the three that can decide and change things.
Imagine a puppet. HTML builds the puppet: head, arms, legs. CSS paints it and dresses it. But it just sits there. JavaScript is the hand inside it. Now it moves, it answers, it remembers, it reacts to you.
These eight ideas are the entire language. Everything else, including React, is built out of exactly these. Learn them once, use them for the rest of your life.
A variable is a box with a name on it, and you put something inside. Later you say the name and get the thing back.
Think of your school backpack. One pocket has a label that says "lunch". You do not care what is inside right now, you just say "give me the lunch pocket" and you get it.
const means the box is sealed, you will never swap what is inside. let means you might change it later. Use const by default, it prevents bugs.
const name = 'Ana'; // never changes let score = 0; // will change score = score + 10; // now it is 10
The computer needs to know if something is words, a number, or a yes/no, because it treats them differently.
Real example: "5" + "5" gives you "55" because those are words being glued together, but 5 + 5 gives you 10 because those are numbers. Same symbols, completely different result. This exact confusion causes more beginner bugs than anything else.
string // words: 'hello', "Ana" number // numbers: 7, 3.5, -20 boolean // yes/no: true, false null // on purpose empty undefined// nobody put anything here yet
An if is a fork in the road. "If it is raining, take the umbrella. Otherwise, do not."
The computer checks whether something is true, then runs one path or the other. That is it. Every login screen, every game over, every "you must be 18" check in the world is this.
One trap: = means "put this in the box". === means "are these the same?". Beginners mix them up constantly.
const age = 15; if (age >= 18) { console.log('You can enter'); } else { console.log('Too young, sorry'); }
Imagine your teacher says "write your name 100 times". A loop is telling the computer "do this 100 times" in one line instead of copying it 100 times.
You will use this every time you have a list: show all 40 products, check all 200 emails, draw all 12 months.
for (let i = 1; i <= 3; i++) { console.log('Round ' + i); } // Round 1 / Round 2 / Round 3 for (const fruit of ['apple', 'mango']) { console.log(fruit); }
A function is a set of steps you give a name, so you can run it again whenever you want without rewriting it.
Like a blender. You put fruit in (the parameters), it does its thing inside, and juice comes out (the return). You do not care how the motor works, you just use it. And you can put in different fruit each time.
Writing the same code twice is the signal to make a function. Always.
function greet(name) { return 'Hello ' + name + '!'; } greet('Ana'); // 'Hello Ana!' greet('Luis'); // 'Hello Luis!' // same thing, shorter (arrow function) const greet2 = (name) => 'Hello ' + name;
An array is a list of things in order, inside square brackets. Like a shopping list where each line has a number.
Careful: computers start counting at 0, not 1. The first item is number 0. Everyone gets this wrong at first, then never forgets it.
const fruits = ['apple', 'mango', 'papaya']; fruits[0]; // 'apple' (the FIRST one) fruits.length; // 3 fruits.push('kiwi'); // add to the end
An object groups related information about one thing, with a label on each piece. An array is "many things"; an object is "many facts about one thing".
A student is not three separate variables floating around. A student is one object with a name, an age, and a grade. When you fetch data from the internet, this is almost always what you get back.
const student = { name: 'Ana', age: 15, passing: true }; student.name; // 'Ana' student.age = 16; // birthday!
Once you have a list, you almost always want to do one of four things to it. JavaScript gives you a word for each one, and professionals use these constantly.
const prices = [10, 20, 30]; prices.map(p => p * 2); // [20, 40, 60] prices.filter(p => p > 15); // [20, 30] prices.find(p => p > 15); // 20 prices.reduce((a, b) => a + b); // 60
The DOM is the bridge between your code and what people see. Without it, JavaScript could calculate things beautifully and nobody would ever notice.
When the browser reads your HTML file, it does not keep the text. It builds a living tree in its memory: body is the parent, the div inside is the child, the text inside that is the grandchild. That tree is the DOM, and what you see on screen is a picture of it.
Here is the key idea nobody explains: JavaScript never edits your HTML file. It edits that tree in memory, and the screen instantly redraws to match. That is why the page changes without reloading, and why refreshing wipes it all away.
Before you can change anything, you have to grab it. You point at it with the same words you use in CSS: .class, #id, or the tag name.
// one element (the first match) const title = document.querySelector('h1'); const btn = document.querySelector('#order-btn'); // all matches, as a list const cards = document.querySelectorAll('.card');
Once you hold it, you can rewrite its text, add or remove a CSS class, or change a style directly.
Best practice: change the class, not the style. Keep the look in CSS where it belongs. JavaScript should say "this is now active", and CSS should decide what active looks like.
title.textContent = 'New title'; card.classList.add('active'); card.classList.remove('hidden'); card.classList.toggle('open'); // on/off switch card.style.background = 'purple'; // works, but prefer classes
This is how every feed, every list, every search result on the internet appears. The HTML file did not contain those 40 products. JavaScript got the data and built 40 boxes.
const li = document.createElement('li'); li.textContent = 'Buy milk'; document.querySelector('ul').append(li); li.remove(); // gone
An event is something that happens: a click, a key press, a form being sent, the page finishing loading. Your job is to wait for it and then react.
Think of a dog waiting for the doorbell. The dog does not check the door every two seconds. It sleeps, and the bell wakes it up. Your code is the same: you do not constantly ask "did they click yet?". You leave a note that says "when a click happens, run this", and then the browser wakes your code up.
Three parts, always: what to watch, which event, and what to do. That is the entire idea of interactive web development.
const btn = document.querySelector('#order'); btn.addEventListener('click', () => { alert('Your pizza is on the way!'); });
The events you will actually use: click, input (typing), submit (a form being sent), keydown, change, DOMContentLoaded (the page is ready).
The browser hands your function a little report about the event. Which element was clicked, what key was pressed, where the mouse was.
e.preventDefault() is the one you will need first: by default, submitting a form reloads the whole page. That one line stops it, so you can handle it yourself.
form.addEventListener('submit', (e) => { e.preventDefault(); // stop the page reloading console.log(e.target); // which element });
When you click a button inside a card inside the page, the click does not only happen on the button. It travels upward: button, then card, then body. That is bubbling, like a bubble rising in water.
This sounds annoying but it is a gift. Instead of putting 100 listeners on 100 items, you put one on the parent and ask "what got clicked?". It is faster, and it even works for items created later. That is event delegation, and it is what separates a beginner from someone who knows what they are doing.
list.addEventListener('click', (e) => { if (e.target.matches('.delete-btn')) { e.target.closest('li').remove(); } });
A library is code somebody already wrote, tested, and gave away, so you do not have to write it yourself.
You do not build a car engine to drive to school, and you do not grow wheat to eat bread. Somebody solved it already, and solved it better than you would in a weekend. Using a library is not cheating, it is how every professional works.
Builds your screen out of small reusable pieces and redraws it automatically when data changes. The most in-demand frontend skill on the job market.
Use when: your app has real state that changes a lot. Overkill for a five-page brochure site.
Turns numbers into graphs. Chart.js is quick and easy, D3 gives you total control and is much harder.
Use when: you need a dashboard. Writing a bar chart by hand is a week you will never get back.
Dates in JavaScript are famously painful. Time zones, leap years, "3 days ago". These fix it.
Use when: you show or calculate dates. Which is nearly every real app.
Checks that data is actually the shape you expect before your app explodes on it.
Use when: you accept forms or data from an API. Never trust incoming data.
Style straight in your HTML with tiny class names instead of writing separate CSS files.
Use when: you already know real CSS. Learn the fundamentals first or you will be stuck forever.
The king of the 2010s. It made DOM work easy back when browsers all disagreed. Modern JavaScript does almost all of it natively now.
Use when: you inherit an old site. Do not start a new project with it, but you will meet it at work.
npm install chart.js downloads it into a folder called node_modules, and writes it into package.json so anyone else on your project gets the exact same versions.import Chart from 'chart.js' pulls it into your file. That is what modules are: splitting your code into files that hand pieces to each other with import and export.Four short lessons I wish someone had given me before I started. Read them in ten minutes, then take your first step.
Forget the movies. Most of the job is connecting things, fixing things, and explaining them clearly.
You need a university degree.
Nobody has ever asked me for one. People ask what you can build and whether you finish it.
Programmers know everything by heart.
You look things up and use AI every day. You get paid to solve problems, not to memorize.
The job is writing genius algorithms.
Most of it is plumbing: moving data between systems, keeping things running, and talking to people.
You have to live abroad to earn well.
From Bolivia you can work for clients in other countries. Where you live is no longer your limit.
Everyone feels like an impostor, even people far ahead of you. You build anyway. That is the only difference.
One direction, one real project, one real person who sees it. Then repeat.
Do not try to learn everything. Take the path quiz and choose one direction.
Build it yourself instead of watching tutorials. A small script or a one page site is enough.
A friend, a teacher, or a small business near you. Their feedback teaches you more than polish.
Repeat the loop with a harder project. Do not wait to feel ready. That feeling comes after you act.
Between "I should learn this" and actually starting. Start today, not on Monday.
Doing beats watching. Small and often beats long and rare.
Try, get stuck, then learn exactly what you needed. It sticks because you needed it.
Watching a whole course before you touch anything.
Learn the small part the thing in front of you needs, then keep going.
Learning a whole framework just in case.
Write a short note or explain it to a friend. If you can explain it, you really know it.
Rereading your notes.
AI makes you faster, but its answers are often almost right. Catching the mistake is the skill people pay for.
Copying whatever it gives you.
One focused hour a day beats ten hours once a month. A project you can show beats a certificate.
Most wasted time is not laziness. It is doing things that feel productive and are not.
Build your own version without following along.
Learn enough to start and fill the gaps as you hit them.
Go deep on one. Tools change, the basics do not.
Finish the ugly version and show it. Done beats perfect.
Share what you build. Feedback and proof matter more than polish.
Compare yourself to who you were last month.
Pick a direction and build something this week. Everything in this academy is here to save you the months I lost.
Not sure what to study? Answer a few questions and we'll tell you where to start, based on how you like to work and what you want.
Start with Foundations. It teaches you what a computer really is, how the internet works, how computers think, and which job in tech actually fits you, before you write a single line of code. Then pick a direction. Finish the lessons, pass the exam, earn the certificate.
Short knowledge checks per domain. Take one, get a score, and see your level. Your best score is saved.
Your plan, your profile, and your password.
Business ideas, reflections, notes. Tagged by category and dated, searchable.
Things you've learned, tagged by domain, with the source and what you can now do with it.
A prioritized wishlist with status and resource links. Tap a status chip to move it forward.
The certs you're pursuing: provider, cost, status, exam date, and study progress.
Understand how computers really work before you write a line of code, practise with real puzzles and a real editor, then find the path in tech that fits you.
Most students choose a career from a job title they half understand, then a third of them change course or drop out. Brain Academy fixes that before university: what the field really is, what the jobs are really like, and how computers actually think.
It was built in Santa Cruz by a working engineer who taught himself all of it, so the advice is about what works, not what a syllabus says should.
A 60 to 90 minute session with a working engineer, and a platform every student keeps using afterwards.