90 lines
2.8 KiB
Markdown
90 lines
2.8 KiB
Markdown
---
|
|
type: story
|
|
title: "How to Learn Here"
|
|
xp: 25
|
|
duration: 25
|
|
difficulty: 1
|
|
---
|
|
|
|
# How to Learn Here
|
|
|
|
> **[INCOMING — Mission Control, Earth]**
|
|
>
|
|
> Cadet, take a breath. You've spent the morning in the shell.
|
|
> Before we take you to Git, we need you to know how learning actually
|
|
> works in this program.
|
|
>
|
|
> Cadets who finish the program share three habits. Cadets who quit
|
|
> share three different ones. We're going to tell you which is which.
|
|
>
|
|
> [TRANSMISSION CONTINUES]
|
|
|
|
## Rule 1 — Understand Every Line
|
|
|
|
You will use AI here. Claude, ChatGPT, our onboard NAV-7 — whatever
|
|
you reach for. We don't forbid it. We *expect* it. The world you're
|
|
training to enter assumes AI fluency.
|
|
|
|
But there is one rule that does not bend:
|
|
|
|
**You must be able to explain every line of code you submit.**
|
|
|
|
If AI writes a function and you can't say what each line does and why,
|
|
you have not learned. You've outsourced thinking. The checkpoint will
|
|
catch the gap. The first real project will catch it harder. Use AI as
|
|
a tutor and a sparring partner — never as a ghostwriter.
|
|
|
|
## Rule 2 — Help the Cadet Next to You
|
|
|
|
This is a peer-learning environment. There are no professors here.
|
|
There are people who landed last month, last week, and yesterday — and
|
|
right now, you.
|
|
|
|
Two things follow from that:
|
|
|
|
- **When you understand something, teach it.** Explaining a concept to
|
|
someone else cements it in your own head better than reading it twice.
|
|
- **When you don't understand something, ask.** Your peers solved this
|
|
exact problem hours, days, or weeks ago. Their explanation will
|
|
usually beat ours.
|
|
|
|
The cohort is the curriculum. Treat it that way and the program runs
|
|
on rails. Ignore it and you'll fall behind alone.
|
|
|
|
## Rule 3 — Struggle First, for Fifteen Minutes
|
|
|
|
When you get stuck — and you will, every day — the instinct is to ask
|
|
right away. Resist it.
|
|
|
|
For fifteen minutes, struggle. Re-read the briefing. Read the error
|
|
message slowly. Try one thing. Try a second thing. Notice what you
|
|
expected versus what actually happened.
|
|
|
|
Most of your real learning happens in those fifteen minutes. Skip them
|
|
and you don't just miss the answer — you miss the *thinking*. After
|
|
fifteen, ask. Not before.
|
|
|
|
## Asking a Good Question
|
|
|
|
When you do ask — peer, AI, or staff — three things make a good
|
|
question:
|
|
|
|
1. **Context.** What were you trying to do?
|
|
2. **What you tried.** What approach did you take? What error did you
|
|
see?
|
|
3. **The exact error.** Copy it. Don't summarize it.
|
|
|
|
A good question gets answered in ten minutes. A bad question gets
|
|
ignored for an hour, or worse, gets the wrong answer because nobody
|
|
understood what you meant.
|
|
|
|
> **[CLOSING — Mission Control]**
|
|
>
|
|
> Two days in, you'll have habits. Make sure they're the right ones.
|
|
>
|
|
> Six Git challenges follow. Then a paired battle. Then Python.
|
|
>
|
|
> Keep going.
|
|
>
|
|
> [END TRANSMISSION]
|