Close the notes. Rebuild from memory. Fix broken code. Learn to find answers without asking anyone.
Day 5 of 80 — End of Week 1
No new concepts. Four activities — in this order:
formatter_v1.py from memoryRe-reading your notes feels productive. It isn't. Your brain gets the recognition signal ("I've seen this") without doing any actual learning. Retrieval is different: you close everything and try to produce the knowledge from scratch. That attempt — even a failed one — is what builds the neural pathway. Do the cold rebuild first, before anything else today, before you even open the lesson pages.
Close all lesson pages. Open a blank file. Build formatter_v1.py from memory — the version that takes input for three shots and formats them. Don't look at your working version. Don't open Day 2.
When you get stuck — and you will — sit with it for two minutes before opening anything. The stuck feeling is the learning happening.
New file. formatter_recall.py. Project name, client, three shots with descriptions and platforms, formatted output. Input at the top, output at the bottom. Go.
When you're done, compare it to your actual formatter_v1.py. Note every line that was different or missing — those are the concepts that didn't fully stick yet.
This is a course-wide rule. It applies from today until Week 16. Every time you see an error, before asking Claude, before Googling, before asking anyone:
Only after all five steps: ask Claude, search Stack Overflow, or check the lesson page. Building the discipline of independent diagnosis is the highest-leverage skill you'll develop this year.
Each program below has exactly one bug. Your task:
Do not scroll to the answers until you've spent at least 3 minutes on each one.
This runs without crashing — but the output is wrong. What is it printing, what should it print, and why?
platform = "Kling"
version = "3.0"
print("Platform: {platform} v{version}")Missing f before the opening quote. Without it, Python treats the string as a literal — it prints Platform: {platform} v{version}, not the variable values. Fix: print(f"Platform: {platform} v{version}")
This crashes every time the user types a number. What's the error, and what's the fix?
clips = input("How many clips? ")
duration = input("Duration per clip (seconds)? ")
total = clips * duration
print(f"Total: {total} seconds")input() returns strings. Multiplying two strings crashes with TypeError. Fix: clips = int(input(...)) and duration = float(input(...)).
This runs and saves a file — but the filename contains spaces, which causes problems on some systems. Fix it so the filename uses underscores.
project = input("Project name: ")
filename = project + ".txt"
with open(filename, "w") as f:
f.write("Shot list contents here.")
print(f"Saved to {filename}")Replace: filename = project.lower().replace(" ", "_") + ".txt". This lowercases the name and swaps spaces for underscores before adding the extension.
This crashes before running a single line. Read the error Python gives you and identify the line. What's wrong?
name = "DVP Golf Commercial"
client = "Highland Links
print(f"Project: {name} — Client: {client}")Missing closing quote on line 2: "Highland Links should be "Highland Links". Python sees the string as never-ending, which causes a SyntaxError: EOL while scanning string literal.
This runs without errors but calculates the wrong number. The formula is supposed to give the total duration of a sequence with transitions between clips. What's wrong with the math?
clips = 5
duration = 4.0
transition = 0.5
total = clips * duration + clips * transition
print(f"Total: {total} seconds")There are only clips - 1 transitions between clips (5 clips = 4 gaps). Should be: total = clips * duration + (clips - 1) * transition. Current code gives 22.5; correct answer is 22.0.
Cover the right column and define each term from memory. Uncover to check.
| Term | Definition |
|---|---|
| Variable | A name that holds a value. Created with name = value. The name is a label — the value is what matters. |
| String | Text data, always in quotes. The data type you'll work with most. |
| Integer | A whole number: 5, -3, 100. No decimal point. |
| Float | A number with a decimal: 3.5, 8.7. Division always returns one. |
| Boolean | True or False — Python's way of representing yes/no. |
| F-string | A string prefixed with f where {variables} get substituted at runtime. |
| Method | A function that belongs to a value, called with a dot: "text".upper(). |
| Type conversion | Changing a value's type: int("5") → 5. Required because input() always returns a string. |
| Floor division | 17 // 5 → 3. Divides and rounds down to the nearest whole number. |
| Modulo | 17 % 5 → 2. Returns the remainder after division. |
If you couldn't define 3 or more terms without looking, go back to the relevant lesson and re-read that section. Then close the lesson and try to define it again from memory. Retrieval — not re-reading — is what makes it stick.
The single most important skill for becoming self-sufficient as a developer is knowing where to find authoritative answers. There are two sources you'll use constantly.
The official Python docs at docs.python.org/3 are the ground truth. The best entry point for a beginner is the Built-in Functions reference — it documents every function you've used this week.
Go to docs.python.org/3/library/functions.html. Find the entries for print(), input(), int(), float(), len(), and type(). For each one, read the first paragraph. You don't need to understand everything — just get comfortable with the format.
Python docs show function signatures like: print(*objects, sep=' ', end='\n', file=None, flush=False). Don't panic. You only need to understand what you're using. The parameters after the * are optional — you've been using print("text") which is the simplest valid call. The rest are there when you need more control.
realpython.com — free articles on every Python topic, written for working developers. Unlike ATBS (which is a book you read front-to-back), Real Python is a reference: search for exactly what you need, read that article, move on.
Use these two sources to answer the following questions. Don't ask Claude. Find them yourself — this is the skill.
print("a", "b", sep="-") output? (Python docs — built-in functions)str.strip() and str.lstrip()? (Real Python — Python strings, or Python docs — string methods)round(3.14159, 2) return? (Python docs — built-in functions)Open Week 1/week-1-practice.ipynb in Cursor. Work through every cell — don't skip. The notebook exercises reinforce the concepts through a different medium. Aim for at least 20 minutes here.
.ipynb file directly. Cursor has built-in Jupyter support.pip install notebook, then jupyter notebook. Navigate to the file in your browser.Shift + Enter executes a cell and moves to the next.Debugging code and evaluating AI outputs are the same cognitive process. You don't guess — you read the evidence, form a hypothesis about what went wrong, test the fix, verify the result. The five bugs today are structurally identical to diagnosing why a Veo output failed: read the artifact carefully, identify the cause, not just the symptom.
The documentation skill is equally transferable. Model cards, API reference docs, and internal rubrics all reward systematic reading over scanning. The habit you built today — finding authoritative answers instead of guessing — is the habit that makes you someone who can work independently at a technical level. That independence is what gets you out of tutoring and into building.
failure_tagger.py — Define the failure modes you actually see in AI video and image outputs. Build a script that lets you tag which ones appeared in a given output session. This is the seed of a real annotation taxonomy tool.
from datetime import date
FAILURE_TYPES = """
1. prompt_mismatch — output doesn't reflect the prompt
2. motion_artifacts — flickering, warping, unnatural movement
3. character_instability — subject changes between frames
4. audio_sync — audio doesn't match visuals
5. resolution_degradation — quality degrades mid-clip
6. style_drift — visual style shifts unexpectedly
"""
print("=== DVP Failure Tagger ===")
print(FAILURE_TYPES)
model = input("Model: ")
prompt = input("Prompt (brief): ")
observed = input("Enter failure numbers seen (e.g. 1,3,5 or 'none'): ")
report = f"""
{date.today()} · {model.title()}
Prompt: {prompt}
Failures: {observed if observed != 'none' else 'None observed'}
{'─' * 44}
"""
print(report)
with open("failure_log.txt", "a") as f:
f.write(report)
print("Logged to failure_log.txt")Run this after a few real sessions. Right now it just records the numbers — Week 2 (loops and lists) will let you parse "1,3,5" into individual tags and count which failure type appears most often across your history. That analysis is the kind of thing an evaluation team lead would pay for.
Git is non-negotiable for any technical role. Three commands. That's all you need this week.
Git saves snapshots of your code over time. If something breaks, you can go back. If a potential employer looks at your work, they see a history of real commits — evidence that you actually built things. Starting now means you'll have a visible track record by the time you need it.
$ git init # creates a git repo in this folder
$ git add formatter_v3.py # stage the file you want to save
$ git commit -m "week 1: formatter v3" # save a snapshot with a messageYou can stage everything at once with git add . — but for now, be intentional about what you commit. Run git status to see what's staged. Run git log to see your commit history.
That's it for Week 1. No branches, no GitHub, no pull requests yet. Just: init once, add, commit. Do this at the end of every week from here on.
Open the terminal in your Python Training folder and run the three commands. Stage formatter_v3.py, eval_session.py, and any other files you built this week. Commit with a clear message. Run git log and confirm the commit is there.
A potential employer or collaborator looking at your work right now would find:
How to describe this in one sentence (practice saying this out loud):
"I built a prompt and evaluation logging CLI in Python that formats shot lists, calculates sequence runtimes, and logs AI evaluation sessions with timestamps — all tools I use in my own workflow."
Next portfolio checkpoint: end of Week 2. By then you'll add filtering by platform and a proper failure-type counter.
Before starting Week 2, you should be able to say yes to all of these:
Move to Week 2 if you have these.
formatter_v3.py runs and creates a fileYou're ready for Week 2.
formatter_recall.pyOnly if Goal is fully done.
failure_tagger.py after a real xAI sessionformatter_v3.pyGo back to the relevant day and re-read the section that covers it. Then close the lesson and try to use the concept without looking. Don't move to Week 2 with gaps — these are the foundations everything else builds on.
Next week you'll learn the four concepts that make code actually powerful: if/elif/else (decisions), for loops (repeat without copy-paste), lists (store many values), and dictionaries (structured data). The formatter will handle as many shots as you want, route each one to the right platform automatically, and build a proper data structure instead of numbered variables. Week 2 is where the tool starts feeling like software.