Understand the machine first.
Learn files, folders, terminals, program structure, testing, Git, and how software reaches another person.
01 / CHOOSE
Pick the shortest path to something you want to build.
A path is an ordered dependency chain, not a list of every interesting subject. Start with one row. Add another course only when your current project gives you a reason.
Build what a browser can show.
Begin with document meaning, add visual layout, then learn behavior. Frameworks make more sense after the browser foundations.
Turn input into reliable results.
Python gives beginners a compact language. SQL and backend engineering then connect programs to durable data and network services.
Learn the system around the model.
Reliable AI work needs programming, data discipline, evaluation, and enough mathematics to understand what a result can and cannot prove.
See what abstractions are hiding.
Learn memory, processes, I/O, compilation, concurrency, and the contracts between software and an operating system.
Use Python for a small first win.
Write a command-line program that reads a text file, counts something useful, and writes a report. That project teaches input, values, decisions, loops, functions, errors, and files.
02 / SETUP
Build a workspace you can explain and recreate.
“It works on my computer” is not a starting point. Make the computer’s state visible from the first day.
The five facts to record
- Folder
- Where the project lives and which files belong to it.
- Runtime
- The exact Python, Node.js, Java, compiler, or browser version that executes the work.
- Command
- The complete command that starts the program from a terminal.
- Input
- The arguments, keyboard text, file, or request given to the program.
- Result
- Standard output, changed files, exit status, and any error text.
FIRST WORKSPACE
learning/
├── README.md
├── notes.md
├── examples/
└── project/Put commands and expected results in README.md. Put explanations in your own words in notes.md. Keep copied examples separate from the project you design yourself.
03 / STUDY
Use one active loop for every chapter.
Recognition feels fluent because the page is in front of you. Understanding appears when you can predict, reproduce, change, and explain without copying.
- 01
Predict
Read the objective and concept map. Write what you think the example will do and which idea controls the result.
- 02
Read
Follow the explanation in order. Stop at an unfamiliar term, define it, and connect it to a value or behavior you already know.
- 03
Run
Type or carefully reconstruct the example. Record the command, actual output, and any difference from the published result.
- 04
Change
Change one input, branch, type, or boundary. Predict again before running. One controlled change teaches more than ten copied examples.
- 05
Explain
Describe the mechanism aloud or in writing: what enters, what changes, what leaves, and why the alternative fails.
- 06
Practice
Complete the foundation exercise before opening hints. Use the rubric to inspect the result, then compare the reference reasoning.
- 07
Retrieve
Close the chapter and answer the review questions from memory. Reopen only the exact section needed to repair a gap.
04 / CHAPTER
Know what every part of a NAPOH chapter is for.
The chapter is a learning system. Skipping its feedback stages turns it into an article.
Objective, prerequisites, and map
Name the promised capability, verify required prior knowledge, and preview how the four explanatory sections connect.
Explanation and key idea
Build a mental model before memorizing syntax. Ask what state exists, what operation changes it, and which boundary limits the claim.
Example, output, and walkthrough
Connect each important line to an observable result. Output is evidence; the walkthrough explains the causal chain.
Common mistakes
Study why a plausible approach fails. The goal is to recognize its signature in your own work, not merely avoid one spelling.
Practice and workshops
Produce a new result under stated constraints. Hints should narrow the next decision, while the rubric defines evidence of completion.
Review and understanding check
Retrieve without looking, explain the output, diagnose one failure, and mark completion only when those claims are true.
05 / DEBUG
Debug one fact at a time.
Random edits destroy evidence. A useful debugging step changes one uncertainty into an observation.
- Reproduce.
Write the exact command, input, expected result, actual result, and whether the failure happens every time.
- Read the first useful error.
Start with the earliest diagnostic from your code or boundary. Later messages are often consequences.
- Reduce.
Remove half the input or code while preserving the failure. Repeat until the smallest meaningful case remains.
- Inspect the boundary.
Check type, value, units, shape, encoding, current state, and ownership immediately before and after the suspected operation.
- State one hypothesis.
Use a sentence that can be disproved: “The parser rejects the comma because it expects a dot decimal separator.”
- Run one discriminating test.
Change only the condition that separates the hypothesis from an alternative explanation.
- Repair and protect.
Fix the cause, add a test for the smallest failing case, and rerun nearby cases to detect regression.
06 / PLAN
Use a sustainable four-week first cycle.
Consistency matters more than heroic sessions. Five focused hours each week is enough to complete a real learning loop.
Environment and values
Complete setup, run tiny examples, learn how values are represented, and keep a command-and-output notebook.
Evidence: five reproduced examples and one explanation written without the chapter open.Decisions and repetition
Practice conditions, loops, collections, and small functions. Test empty, one-item, ordinary, and boundary inputs.
Evidence: one program handles at least four named cases.Files, errors, and tests
Read external input, validate it, return useful failures, and protect expected behavior with repeatable tests.
Evidence: a clean run and three intentional failures produce documented outcomes.Small complete project
Build one command-line or browser project from a blank folder. Include setup, examples, tests, and a short design explanation.
Evidence: another person can follow the README and reproduce the result.Begin before you feel ready.
Choose one path, create the workspace, and complete the first chapter’s full loop. Confusion is not proof that you cannot program; it is a signal to reduce the problem until one relationship becomes visible.