Week 1 — Lecture Outline · Intro to Computing & Computational Thinking

Course: Introduction to Computer Science — CS1 / Programming Fundamentals in Python (CSCI 1101) · Silver Oak University (fictional sample) · Prof. Okafor
Objective covered: Objective 1 — Explain computational thinking — what a program and an algorithm are, how code runs, and how to read an error message — and write, run, and trace simple Python programs.
SLOs touched: A (write and run a correct program) · B (trace code and predict output; find and fix a defect)
Meeting pattern: 2 studio sessions × 75 min = 150 min. Segment minutes below total ~150; scale to your own pattern.

Every code output, traced value, and error message in this outline was produced by actually running the code in Python — not hand-traced. Run them live in class; the outputs are exact.

---

Week at a Glance

The week's big question	"What is a program — and how does a computer know what to do when you run one?"
By the end of the week, students can…	(1) explain computational thinking and what an algorithm is; (2) write and run a first Python program with print(); (3) trace a short program and predict its output, then confirm by running it; (4) read an error message and tell a SyntaxError from a NameError to fix a bug.
Key vocabulary	program, algorithm, code, source code, computational thinking, decomposition, syntax, statement, print(), string, argument, expression, operator precedence, comment (#), run/execute, output, error, exception, SyntaxError, NameError, bug, debugging, trace
Materials	slides (Deck 1), the week's readings + video links, a free online Python environment + Python Tutor (links in the readings), one approved chatbot (Gemini / Claude / ChatGPT) for the AI-critique moment and the tutorial
Timing note	8 segments, ~150 min total. Session 1 = Segments 1–4 (~75). Session 2 = Segments 5–8 (~75). This is a studio: code along on the projector and have students type every example into the online environment with you.

---

Segment 1 — Hook & the Promise (8 min) · Session 1 opens

Hook. Put one instruction on a slide: "Make a peanut-butter sandwich." Ask the room to shout the steps while you follow them literally — "put peanut butter on the bread" → you set the closed jar on the closed bag. The room laughs; you can't spread anything. The point lands hard: a computer is exactly this literal. It does precisely what you say, in the exact order you say it, with zero common sense filling the gaps.

The promise (write it on the board): "By Friday you'll have written real code, run it, and read your first error message — and you'll know the one habit that separates people who get programming from people who fight it: run the code, don't guess."

Why it matters line (memory hook): "The computer does exactly what you wrote — not what you meant."

---

Segment 2 — What Is a Program? Computational Thinking (20 min)

Plain language first. A program is a list of precise instructions that a computer carries out in order. The recipe for solving the problem — the steps themselves, independent of any language — is the algorithm. Writing the algorithm down in a language the computer can run (for us, Python) is coding.

Computational thinking = breaking a messy problem into steps a machine can do. Its biggest move is decomposition: take "greet the user by name" and break it into (1) get the name, (2) build the greeting, (3) show it. Each piece is small enough to turn into code.

One worked "algorithm before code" example (do it out loud).

Problem: find the larger of two numbers.
Algorithm (plain English): look at both numbers; if the first is bigger, the answer is the first; otherwise the answer is the second.
"Notice we solved it in English first. Code is just translating a clear plan into exact instructions. A fuzzy plan makes buggy code."

The clarification students always need: the computer has no judgment. It will not "figure out what you meant." Every step has to be spelled out, in order, exactly. That's not a flaw — it's why computers are reliable.

---

Segment 3 — Your First Program: print + the Run Loop (the code-along) (24 min)

Set it up: "Open the online Python environment from the readings. Type exactly what I type. We're going to make the computer say something."

Code-along, step by step (everyone types each line and runs it):

Step 1 — one line:

print("Hello, world!")

Press Run. Output:

Hello, world!

"print is a command that displays whatever you put in the parentheses. The thing in quotes is a string — text. The parentheses hold the argument you're giving to print."

Step 2 — add a second line; programs run top to bottom:

print("Setting up")
print("Ready to code")

Output:

Setting up
Ready to code

"Two statements, run in order. Each print ends its line and the next one starts fresh below."

Step 3 — print can take several values, separated by commas:

print("CS", "is", "fun")

Output:

CS is fun

"Commas put a single space between the pieces automatically."

The run loop — name it and put it on a slide: EDIT → RUN → READ the output → FIX → repeat. "This loop is the whole job. You will run code thousands of times this term. Running is not the reward at the end — it's how you find out what your code actually does."

---

Segment 4 — Trace This Code: What Does It Print? (20 min) · Session 1 closes (~75)

Set it up: "Before we run a program, a real programmer predicts what it will do. Let's practice tracing — reading line by line and saying the output — and then we run it to check."

Worked trace #1 (reveal one line at a time; have the room predict, then run):

print(2 + 3 * 4)

• Trace: Python evaluates the expression inside print first. Operator precedence: multiplication before addition. 3 * 4 is 12, then 2 + 12 is 14.
• Predicted output: 14. Run it. Actual output:

14

"Most people's gut says 20 (adding left to right). The computer follows math precedence: * before +. This is exactly why we run code instead of trusting our gut."

Worked trace #2 — parentheses change the order:

print((2 + 3) * 4)

• Trace: parentheses force 2 + 3 = 5 first, then 5 * 4 = 20.
• Output (run-verified):

20

Worked trace #3 — the "2" + "3" trap (quotes change everything):

print("2" + "3")

• Trace: these are strings, not numbers. + on two strings joins them (concatenation), it doesn't add. So "2" + "3" is "23".
• Output (run-verified):

23

Compare, without quotes:

print(2 + 3)

Output:

5

"Same +, totally different jobs. With quotes it's text-joining; without quotes it's arithmetic. The quotes are not decoration — they change the meaning."

Quick interaction (rapid-fire, ~5 min): put three tiny programs on a slide; for each, students predict the output solo (20 sec), then you run it. Suggested: print(10 / 4) → 2.5; print("3 + 4") → 3 + 4 (it's a string, printed literally); print(7 - 10) → -3.

---

Segment 5 — Reading Errors: SyntaxError vs NameError (22 min) · Session 2 opens

Hook back in: "Last session you wrote working code. Today you'll write broken code on purpose — because reading errors is half of programming, and the error message is the computer helping you."

Plain language first. When Python can't run your code, it stops and prints an error message (an exception). The trick: read it from the bottom up. The last line names the kind of error and gives a hint; the lines above point at where.

Live demo #1 — a NameError (the most common beginner error):

print(Hello)

Run it. Python stops with (run-verified):

NameError: name 'Hello' is not defined

"We forgot the quotes. Without quotes, Python thinks Hello is the name of something — a variable — and goes looking for it. There's nothing called Hello, so: NameError. The fix is to make it a string:"

print("Hello")

Output:

Hello

Live demo #2 — a SyntaxError (the sentence isn't even grammatical):

print("hi"

Run it. Python won't even start (run-verified):

SyntaxError: '(' was never closed

"A SyntaxError means the code breaks Python's grammar rules — here, an open parenthesis with no closing one. Python catches it before running a single line. The fix: add the )."

Land the distinction (put it on a slide):
- SyntaxError = the code is grammatically broken (missing ), missing quote). Python won't run any of it.
- NameError = the grammar is fine, but you used a name Python doesn't know (often a forgotten quote, or a typo/capitalization).

Misconception + cure:
- ❌ "An error means I broke the computer / I'm bad at this."
✅ Cure: an error is the computer pointing at the problem. Every professional sees dozens a day. Read the last line; it tells you what's wrong.

---

Segment 6 — Spot & Fix the Bug (the debugging demo) (18 min)

Set it up: "Here's a program that's supposed to print a greeting but doesn't. Let's debug it together — find the bug, predict the fix, run to confirm."

The buggy program (put it on a slide exactly as is):

Print("hello")

Debug it out loud:
1. Run it. Python says (run-verified): NameError: name 'Print' is not defined.
2. Read the message: Python doesn't know a name called Print. But we meant the print command…
3. The bug: capital P. Python is case-sensitive — Print and print are different names, and only lowercase print is the built-in command.
4. The fix, then run to confirm:

print("hello")

Output:

hello

Land the key idea: debugging is a loop, not a flash of genius. Run → read the error → form a guess about the cause → make one change → run again. You'll do this constantly, and getting good at it is most of what "getting good at programming" means.

A second quick bug (let the room solve it): print("hello) → run-verified SyntaxError: unterminated string literal. The fix: the closing quote is missing — print("hello").

---

Segment 7 — Misconceptions Round-Up + Quick Interaction (20 min)

Name the misconceptions out loud, then cure each:

• ❌ "The computer understands what I mean."
  ✅ Cure: it executes exactly what you wrote, literally and in order. Precision is the job.
• ❌ "= and == are the same." (preview of Week 2/4)
  ✅ Cure: not yet today's topic, but flag it: = will store a value, == will compare — we'll meet both soon.
• ❌ "Adding strings adds numbers."
  ✅ Cure: "2" + "3" is "23" (joins text); 2 + 3 is 5 (adds numbers). Quotes decide.
• ❌ "print(2 + 3 * 4) is 20."
  ✅ Cure: precedence — * before + — so it's 14. When unsure, run it.
• ❌ "A red error message means I failed."
  ✅ Cure: it's a map to the bug. Read the last line.

Interaction — Predict-then-Run (rapid-fire, ~8 min): put four programs on a slide; students predict each output solo (30 sec), compare with a neighbor (1 min), then you run all four. Suggested with run-verified outputs: print("CS", "is", "fun") → CS is fun; print((2 + 3) * 4) → 20; print("2" + "3") → 23; print(5 * 2) → 10. Tally how many the room got right — celebrate the misses as "this is why we run code."

---

Segment 8 — Technology Workflow + AI-Critique, Callback & Hand-off (18 min) · Session 2 closes (~75)

Technology workflow — the everyday loop, on demand:
1. Open the free online Python environment (link in the readings). Type your code.
2. Press Run. Read the output — or the error.
3. If it's an error, read the last line first; it names the problem.
4. Make one change, run again. Repeat. To watch code run step by step, paste it into Python Tutor and click forward.

AI-critique moment (students verify, not consume):

Paste this to an approved chatbot: "What does this Python program print? print(2 + 3 * 4) — and also print('2' + '3')."
Then check its work by running both yourself. Chatbots usually get these, but they routinely predict the wrong output on slightly trickier code — and they'll state it with total confidence. Your job all semester: the tool drafts, you run it and judge. This is exactly how the weekly Lecture Tutorial and Coding Lab work — you catch the model, not trust it.

Callback + tease:
- Callback: "Today: what a program is, how to write and run one with print, how to trace output, and how to read an error. Everything else this term builds on this loop."
- Tease next week: "Right now our programs can only say fixed things. Next week we give them memory — variables — so a program can hold a value, do math with it, and change what it does. We'll meet int, float, str, and bool."

Hand-off (the week's graded work):
- Lecture Tutorial 1 (AI tutor, share-link submission) — computational thinking, print, tracing, and reading errors.
- Quiz 1 and Discussion 1 ("Explain a Program to Your Grandparent") and Assignment 1 ("Your First Programs").
- Coding Lab 1 — "Hello, Run, Fix" — write, run, trace, and debug your own first programs in the online environment.

---

Instructor FAQ — Common Stumbles

Student says / does	Quick cure
"Nothing happened when I ran it."	Did they use print(...)? Without print, a program can compute a value but never shows it.
Writes Print(...) or PRINT(...).	Python is case-sensitive; only lowercase print is the command (NameError otherwise).
Forgets the quotes: print(Hello).	No quotes → Python reads Hello as a name it doesn't know → NameError. Wrap text in quotes.
Thinks print(2 + 3 * 4) is 20.	Operator precedence: * before + → 14. Run it to confirm.
Surprised "2" + "3" is 23.	+ on strings joins them; + on numbers adds. Quotes change the meaning.
Panics at a red error message.	Read it bottom-up: the last line names the error (SyntaxError vs NameError) and hints at the fix.
Mismatched parentheses/quotes.	SyntaxError: '(' was never closed / unterminated string literal — add the missing ) or ".
"I'll just read about it instead of running it."	Reading isn't enough in CS1. The loop is edit → run → read → fix. Always run.

---

Scope flag

This outline stays within Objective 1 (computational thinking; writing/running a first program; tracing simple print output; reading basic errors). Variables and data types are Week 2 and only previewed here; conditionals, loops, and functions come later. We use only print, string literals, simple arithmetic inside print, comments, and the two most common errors — the right floor for day one. Python and its error names (SyntaxError, NameError) are referenced factually; the instructor and institution remain fictional. Every output shown was produced by running the code.