Skip to content

LEARNING_GUIDE.md

Latest commit

 

History

History
111 lines (79 loc) · 3.65 KB

LEARNING_GUIDE.md

File metadata and controls

111 lines (79 loc) · 3.65 KB
Raw
layout default
title How to Learn
nav_order 3
permalink /learning-guide/

Learning Guide

This course is designed for independent study. You do not need to understand a page after one reading. Programming becomes clear through a cycle of reading, predicting, typing, running, changing, and explaining.

Use one learning folder

Create one folder for the course and one subfolder for each chapter. Keep experiments even when they fail; a fixed mistake is useful evidence of learning.

python-intermediate-learning/
├── 01-pythonic/
├── 02-functions/
├── 03-generators/
└── projects/

Use .py files instead of typing every example only in the interactive prompt. Files are easier to rerun, compare, and debug.

The six-step lesson routine

  1. Recall: Before reading, say what you remember about the Basic prerequisite.
  2. Read: Read one section, including the expected result and important notes.
  3. Predict: Guess the output before running the code.
  4. Type: Type the example yourself. Copying hides small decisions.
  5. Change: Change one value, condition, or input and predict again.
  6. Explain: Describe the code in your own words without looking at the page.

Then solve the Bug Hunters and ten practice problems. Complete homework only after the smaller questions.

How to read a larger example

Do not try to understand every line at once. Use this order:

  1. Find the input.
  2. Find the final output or return value.
  3. Read the names of functions and classes.
  4. Trace one normal input from top to bottom.
  5. Trace one empty or invalid input.
  6. Only then study each implementation detail.

Draw boxes and arrows when objects collaborate:

CLI input -> service rule -> repository -> stored data
                    |
                    -> useful error

How to use practice help

  • Spend at least ten focused minutes on a problem.
  • Write an example input and expected output.
  • Open only the hint with the same number.
  • Return to your code before viewing the solution idea.
  • Compare approaches; do not replace your work blindly.
  • Close the solution and write the program again from memory.

A solution idea is not always a complete production program. Add validation and tests appropriate to the problem.

A calm debugging routine

  1. Reproduce the failure with the smallest input.
  2. Read the final error line first.
  3. Find the file and line number.
  4. Inspect the values just before that line.
  5. State what you expected and what actually happened.
  6. Change one cause at a time.
  7. rerun the original case and an edge case.

Never hide an error with a broad except Exception unless you have a clear boundary, log the failure, and know how the program should recover.

Suggested pace

There is no deadline. A useful rhythm is:

  • Day 1: explanation and typed examples
  • Day 2: Bug Hunters and problems 1–5
  • Day 3: problems 6–10 and review
  • Day 4: homework and checkpoint

One difficult chapter may need two weeks. Understanding is more important than speed.

When to move forward

Move to the next chapter when you can:

  • explain the main idea without reading;
  • solve at least eight practice problems;
  • fix the Bug Hunter examples;
  • write and run a few useful tests;
  • complete the homework with only occasional reference to the lesson.

If you cannot, repeat the smallest unclear section rather than rereading the whole chapter.

Asking for useful help

Share four things:

  1. the goal;
  2. the smallest code that still fails;
  3. the complete error message;
  4. what you expected and already tried.

That information helps a teacher or teammate explain the cause instead of simply giving an answer.