Unit 1 · Web Foundations

Lesson · Unit 1 · 8 min read

Dev workflow & the IDE, the loop you'll spend your career in.

Tools matter less than the loop. Senior engineers run a four-step cycle thousands of times a year. The faster and tighter that loop, the better the code that comes out of it.

Section · 01

Project management — Waterfall vs Agile

You will work in one of two project methodologies, or some mutant hybrid. Know what each is so you can roll with whichever shop you end up in.

Waterfall  →  Plan everything → design everything → build → test → ship.
              Linear. Long cycles. Hard to change mid-flight.
              (Good for: regulated industries, hardware, fixed-scope contracts.)

Agile      →  Plan a little, build a slice, ship, learn, repeat in 1-2 week sprints.
              Iterative. Embraces change. Most modern software.
              (Good for: web, SaaS, anything where requirements evolve.)

The real distinction isn’t the labels — it’s batch size. Waterfall ships in months; agile ships in weeks or days. Smaller batches mean faster feedback, fewer bugs piled up, and shorter distance between “we should change this” and “we changed it.”

Section · 02

Structure patterns

Most websites use the same three patterns at different layers:

MVC          — Model · View · Controller  (Rails, Laravel, classic web frameworks)
Component    — UI built from reusable components (React, Vue, Svelte)
Layered      — Presentation → Business logic → Data (any backend with a service layer)

Don’t memorize these. Notice them in whatever codebase you touch and ask “where does this kind of code live?” The answer is usually predictable from the pattern.

Section · 03

Version control — git in one paragraph

Git is a tool that tracks every change to your code as a sequence of commits. You can rewind, branch off to try something, merge changes from teammates, and never lose work. GitHub is a website that hosts git repositories. You will use both, every day, forever.

The five commands you'll use 99% of the time:

git status                         # what's changed
git add .                          # stage changes
git commit -m "fix: nav overflow"  # save a checkpoint with a message
git push                           # send checkpoints to GitHub
git pull                           # pull teammates' changes

The other 1% — rebasing, cherry-picking, bisecting — you learn when you need it. Don’t front-load it.

Section · 04

The IDE you should actually pick

An IDE (Integrated Development Environment) is a text editor with a debugger, terminal, linter, and git client glued on. The state of the industry as of 2026:

VS Code     — Free. Most popular. The default unless you know better.
Cursor      — VS Code with AI built in. Very popular among working devs.
JetBrains   — IntelliJ/WebStorm. Paid. Heavy. Beloved by some, hated by others.
Neovim      — Terminal-based. For people who write a lot of YAML about their config.
Sublime     — Fast and minimal. Niche but loyal users.

Pick one and learn its keybindings. Don’t spend three months tweaking themes. The IDE is for moving fast in the inner loop (see below), not for being your hobby.

Section · 05

The development inner loop

Every productive engineer runs the same four-step loop, dozens of times an hour:

1. Write a small change.
2. Run it (or refresh the page).
3. Read what happened — the output, error, screenshot, log.
4. Decide the next change.

The number-one predictor of how fast you ship is how tight this loop is. Hot module reload, instant tests, fast type errors, a good debugger — these all matter because they shorten the cycle. A 1-second loop and a 30-second loop produce vastly different codebases over a year.

Read errors, don’t skim them

The single biggest skill gap between juniors and seniors is reading errors carefully. The traceback usually tells you exactly what’s wrong and exactly which line. Beginners panic and start guessing. Slow down, read the bottom line of the error, search the exact text, then act.

Section · 06

Best practices that compound

Five habits that pay off forever:

1. Write small, focused commits. Future-you needs to read them.
2. Use real names. "data" and "stuff" are not names. "userOrders" is.
3. Delete dead code aggressively. Comments, unused imports, the lot.
4. Don't optimize before measuring. Most "slow" code is not the slow code.
5. Read other people's code. Skim a popular open-source project monthly.

You now have everything you need to start touching code. Unit 2 is HTML and CSS — the markup that everything else builds on. Onward.