Course 1 · Roadmap

How to Use This Curriculum

You have the map, the schedule, and the destination. This last orientation chapter is about how to study so the months you're about to spend actually stick — the learning techniques that work, how to use this curriculum's built-in scaffolding, the one repo you'll carry the whole way, and the single most valuable skill in all of engineering: what to do when you're stuck.

How to learn technical material effectively

Most people study the way they were taught in school: read it, highlight it, re-read it before the test. That feels productive and it barely works. The brain learns by retrieving information, not by re-seeing it. Four techniques do the heavy lifting, and this whole curriculum is built around them:

Active recall over re-reading. After you read a section, close it and say (or write) what it meant in your own words. The effort of pulling the idea out of your head is what wires it in. Re-reading just makes familiar text feel easy — a trap.
Spaced practice. Reviewing a concept a few times across several days beats cramming it once. When chapter 07 reuses an idea from chapter 02, that's not repetition for its own sake — it's the spacing that moves it into long-term memory.
The "explain it back" (Feynman) test. If you can't explain a concept in plain words to an imaginary beginner, you don't understand it yet — you've just memorized the shape of it. The gaps where you stumble are exactly what to re-read.
Learn by building, not just reading. You cannot read your way to being an engineer any more than you can read your way to swimming. The reading exists to make the building possible. The exercises and the capstone are where the skill actually forms.

Put those together and you get a loop. Run it on every meaty section — not just once per chapter:

THE STUDY LOOP (run it per section, not per chapter) ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 1 READ │────▶│ 2 DO │────▶│ 3 CHECK │ │ a section│ │ type the │ │ "you │ │ actively │ │ code / │ │ should │ │ │ │ exercise │ │ see…" │ └──────────┘ └──────────┘ └────┬─────┘ ▲ │ │ ▼ │ ┌──────────┐ ┌──────────┐ └───────────│ 5 REPEAT │◀────│ 4 TEACH │ next │ space it │ │ explain │ section │ over days│ │ it back │ └──────────┘ └──────────┘

Why "teach" is in the loop

Teaching is the highest form of retrieval — it forces recall, ordering, and plain language all at once. You don't need a real audience. Explain it to a notebook, a rubber duck, or a study-group channel. If the explanation comes out tangled, you just found the part to study next.

How to use this curriculum's structure

Every chapter is built with the study loop baked in. Here's how to actually use each piece instead of skimming past it:

Feature you'll see	How to use it
✓ Check yourself list	Treat each bullet as a question to answer out loud before moving on. A silent "yeah, probably" is not a yes. If any bullet is shaky, scroll back — that's the loop's "check" step.
Exercises (the `<details>` blocks)	Attempt the whole thing before opening the solution. The struggle is the learning; a solution you only read is not a skill you own.
Code blocks	Type them, don't paste. Your fingers learn what your eyes skip, and the typos you make (and fix) teach you how the tool really behaves.
"You should see…" checkpoints	In hands-on chapters, stop and confirm the output matches before continuing. Debugging one wrong step now is far cheaper than discovering five steps' worth of drift later.
Setup boxes	Do the install/run steps in order, once, at the start of a hands-on chapter. Don't skip ahead and improvise — the later steps assume the earlier ones ran.

The peek temptation

Opening the solution "just to get unstuck" feels efficient and quietly robs you of the exact rep you came for. Rule of thumb: give every exercise an honest attempt and a time-box (more on that below) before you peek. A wrong answer you then correct teaches more than a right answer you read.

Set up your companion repo now

From Course 2 onward you'll build up a single git repository called mini-griddp. By the end it is your portfolio — the thing you show an interviewer. You don't need to understand git yet (full git teaching arrives in Course 2 and Course 5); right now we're just establishing the habit of working in one repo and committing as you go. Create it today so it's ready:

create the repo (run once)

mkdir mini-griddp
cd mini-griddp
git init
echo "# mini-griddp" > README.md
echo "My data platform learning repo." >> README.md
git add README.md
git commit -m "chore: initialize mini-griddp"

From here on, the rhythm is simple: commit small and often. Finished an exercise? Commit it. Got a script working? Commit it. Each commit is a tiny save point you can return to — and a visible record of your progress.

the everyday rhythm

# after you finish a chunk of work:
git add .
git commit -m "feat: solve ch02 group-by exercise"

Optional: learn in public

Pushing mini-griddp to a free GitHub account turns six months of effort into a visible, dated trail of growth — and recruiters do look. You can create the empty repo on GitHub and connect it with git remote add origin <url> then git push -u origin main. If that's unfamiliar, don't worry: Course 2 walks through it properly. Local-only is completely fine to start.

What to do when you get stuck

This is the most important skill in the whole curriculum, so read it twice. You will get stuck — constantly, and forever. Getting unstuck efficiently is most of what separates a working engineer from someone who quits. It is a learnable process, not a talent. Here is the process:

Read the error message slowly. Out loud, start to finish. Errors are written to you and usually name the file, the line, and what went wrong. Beginners panic and skip them; engineers read them first.
Isolate and minimize. Cut the problem down. Comment out half the code, or run the one line in isolation, until you have the smallest thing that still breaks. The bug usually becomes obvious once it's alone.
Rubber-duck it. Explain the problem, line by line, to a duck/notebook/wall. Saying it forces the assumptions into the open, and you'll often spot the bug mid-sentence.
Search well. Paste the key part of the error (drop your filenames and IDs) plus the tool name. Prefer official docs and recent answers over random forum posts.
Time-box it. Set a limit — say 30 minutes of genuine effort. Under it, keep wrestling; the struggle is teaching you. Over it, stop spinning and ask. Both halves of that rule matter.
Ask well. When you do ask, show what you tried, the exact error, and what you expected. People answer good questions fast — and writing the question often solves it.

A quick triage table for the moment things break:

Symptom	First move
A red error / stack trace appears	Read the last line first — it's usually the real cause — then work upward.
"It worked yesterday / on the example"	Find what changed. Diff your code against the working version (`git diff`) — the bug is in the change.
No error, but the output is wrong	Print/inspect the data at each step. Wrong output = wrong assumption about the data, almost always.
"Command not found" / won't start	It's an environment problem, not a code problem. Re-check the chapter's Setup box and that you're in the right folder/venv.
You've stared at it for 30+ minutes	Stop. Walk away for five minutes, or post a well-formed question. Tunnel vision is real.
You genuinely don't understand the concept	This isn't a debugging problem — go back to the reading and run the study loop on it.

Good places to ask: the official docs and "getting started" guides for whatever tool you're using, the tool's community (Slack/Discord/forum), and broad Q&A communities for general programming. You'll meet the specific communities as the relevant tools show up in later courses.

Using docs and AI assistants well

Documentation and AI assistants are part of every real engineer's toolkit — pretending otherwise is one of the myths we dropped in chapter 00. Used well, they're a massive accelerator. Used badly, they quietly stop you from ever learning. The difference is whether you stay in charge of your own judgment.

Great use (accelerates learning)	Dangerous use (replaces it)
"Explain this error message in plain English."	"Just write the whole exercise for me."
"What does this unfamiliar syntax do, line by line?"	Pasting generated code you can't read and moving on.
"Give me three approaches and the trade-offs."	Taking the first answer without checking it against the docs.
"Quiz me on this chapter / poke holes in my explanation."	Outsourcing the thinking and keeping only the output.

The one rule

Never commit code you can't explain. If you couldn't walk a colleague through every line of it, you don't understand it — and you'll be helpless the moment it breaks (and in the interview when they ask). Use AI to understand faster, never to skip understanding. When it hands you something, your job isn't done until you can teach it back.

Assistants also hallucinate confident nonsense, especially about specific tools and flags. Treat their output as a smart, fallible colleague's draft: helpful, worth verifying against the real docs before you trust it.

The right mindset

Three things to hold onto for the months ahead. Progress over perfection: a messy working pipeline beats a beautiful plan, every time — ship the small thing. Embrace being a beginner: confusion isn't failure, it's the feeling of your edge moving outward; the discomfort is the work. And trust the compounding curve: early on it feels like nothing connects, then around the foundations everything starts clicking into the same few patterns and your pace accelerates. The people who make it aren't the fastest starters — they're the ones who kept showing up past the flat part of the curve.

✓ Check yourself

Before you leave orientation, make sure you can answer "yes" to these:

Can you name the five steps of the study loop (read → do → check → teach → repeat)?
Do you know the "type it, don't paste it" and "attempt before you peek" rules — and why they exist?
Can you describe your get-unstuck process, including your own time-box limit?
Do you know the one rule about AI: never commit code you can't explain?
Is your mini-griddp repo created with at least one commit?

Exercise — Initialize your repo & write your study loop

Two small actions, done now. First, create mini-griddp and make your first commit. Second, write your study loop on an index card (or a sticky note) and put it where you study — you'll glance at it for the next six months.

part 1 — your first commit

mkdir mini-griddp
cd mini-griddp
git init
echo "# mini-griddp" > README.md
git add README.md
git commit -m "chore: initialize mini-griddp"

# confirm it worked — you should see one commit:
git log --oneline

You should see a single line like a1b2c3d chore: initialize mini-griddp. If git reports it isn't installed, that's an environment problem — Course 2's setup will fix it; for now just note it.

Part 2 — the index card. No hidden solution; here's a sample of what to write:

study-loop.card

READ a section actively (then close it)
DO   the code / exercise — TYPE it, attempt before peeking
CHECK "you should see…" + ✓ Check yourself
TEACH explain it back in plain words (rubber duck)
REPEAT space it over days

STUCK? read the error → isolate → rubber-duck →
       search → 30-min time-box → ask well
RULE: never commit code I can't explain

That card is the whole method on one piece of paper. Glance at it whenever a chapter starts to feel like passive reading.

That's the end of orientation — you have the map, the schedule, the method, and your repo. Now the hands-on work begins. → Orientation & Setup