Your First Code Defense

Core path: 30 minutes

Can you explain what happened without hiding behind "it worked" or "it broke"?

By now you have several versions of the same tiny program:

• a working version;
• a version with a missing parenthesis;
• a version with a misspelled function name; and
• a prediction challenge that treated similar-looking code in three different ways.

That is enough evidence to do something beginners are rarely asked to do this early: defend your explanation of the program.

Not defend it like a lawyer. Defend it like an engineer.

Start with the claim you can actually prove

Weak claim:

My program works.

Stronger claim:

Running python hello.py produced all five required lines in the correct order with no error output.

The second claim tells another person what was tested and what evidence supports the conclusion.

Re-run the known-good baseline if you need fresh evidence before making that claim:

Run the code to see output.

This distinction is going to follow you through the entire course.

Later, "works" may mean automated tests passed. It may mean an API returned the expected structure. It may mean a Git diff stayed inside the approved files. It may mean an AI-generated change met the specification without quietly weakening the tests.

The tools change. The standard does not: confidence is not evidence.

Reconstruct one failure

Choose one of your broken versions.

Put the working and broken source next to each other.

For example:

# working
print("SYSTEM READY")

# broken
print("SYSTEM READY"

Now explain the failure without skipping the middle:

I removed the closing parenthesis.
        ↓
The function call became structurally incomplete.
        ↓
Python reported a syntax problem near that statement.
        ↓
I restored the parenthesis.
        ↓
The program produced the required output again.

The arrows are not decoration. Each arrow means caused or led to.

If you cannot explain one of those connections yet, that is the part you need to inspect again.

Separate source, execution, and evidence

Look back at these three layers:

SOURCE CODE
what you wrote

EXECUTION
what Python attempted to do

EVIDENCE
what you observed afterward

A common beginner habit is to collapse all three into one sentence:

Python is broken.

That tells us almost nothing.

A better diagnosis might be:

The source contains pritn(...). Python starts executing the file, reaches a name it cannot resolve, and reports an error. The typo is in my source; the interpreter is doing its job by reporting it.

That is a much stronger mental model.

The screen is not reading your mind

This is where the Week 1 idea comes back around.

In Lesson 1, the robot could not infer what "go over there" meant. In Lesson 4, Python could not infer that pritn was supposed to mean print.

Same problem. Different scale.

The machine receives the representation we give it, not the intention we wish we had expressed.

That is why software work rewards people who can slow down and inspect what is actually present in the system.

The movies make hacking look like speed. Real technical work is often the opposite: stop, read the output, check the file, verify the command, and make one controlled change.

Less cinematic. Much more useful.

A two-minute code defense

Suppose your instructor points to this line:

print("10" + "5")

A weak answer is:

It makes 105.

A stronger answer is:

Both values are inside quotation marks, so Python treats them as text. The + operator joins the two strings instead of adding numbers. That is why the observed output is 105 instead of 15.

Use the same three-line prediction surface from Lesson 4 if you want to verify the mechanism before defending it:

Run the code to see output.

The output is only the beginning of the answer. The explanation names the mechanism.

Now do the same thing with your own artifact.

Choose one item from your Week 1 work:

• one working print() line;
• one broken line;
• one error report; or
• one prediction from the three-output challenge.

Prepare a short explanation that answers:

• What exactly is in the source?
• What did Python do with it?
• What evidence did you observe?
• What changed when you repaired or modified it?

Do not memorize a speech. Understand the chain well enough that somebody can interrupt you with a question and you can still explain it.

What Week 1 should leave behind

You do not need to leave Week 1 knowing every Python command.

You should leave knowing something more useful:

• a problem has to be turned into precise instructions;
• source code is a representation of those instructions;
• the source file and the running program are different things;
• the interpreter is software that processes and executes Python programs;
• output and errors are evidence about what actually happened;
• small source changes can produce different behavior; and
• when behavior surprises you, inspect before guessing.

Week 2 adds more tools and a real development environment around those ideas.

The hidden architecture is starting to show.