In-Class Group Exercise
Form a team of three or more. Together, pick a problem you actually care about and write a Python program that solves it — then present it to the class in 2 minutes.
The problem is open-ended on purpose. There is no single right answer, and you are not being graded on how impressive the code looks. You are being graded on whether you can explain it.
Timeline
| Time | What |
|---|---|
| ~5 min | Discuss as a team and agree on the problem |
| ~25 min | Write the program, test it, and prepare your explanation |
| 2 min per team | Present |
Step 1 — Choose a Problem
Discuss as a team and pick something small enough to solve in one class, but real enough that you can say why it matters. A few directions to spark ideas:
- Something you do by hand every week and would rather automate
- A calculation from another course (finance, accounting, statistics)
- A simple business question — pricing, splitting costs, scheduling, ranking
- A small game, quiz, or simulation
Keep the scope small. Aim for roughly 30 to 60 lines of code, not counting any sample data — one clear input, one clear output, and a core idea you can explain in under a minute. A tiny program that works and that you fully understand beats an ambitious one that half-runs and nobody on the team can explain. If your idea feels too big, cut it down to the single most useful piece of it: one calculation, one decision, one report.
You may use anything from the Python Basics lecture: variables, f-strings, flow control, lists, dictionaries, sets, comprehensions, and functions. You do not need any library beyond the standard Python you already know.
Everyone on the team must be able to answer: why did we choose this problem?
Step 2 — Data (If Any)
Your program may need data, or it may not.
- If it uses data, be ready to say where the data came from, what each column or key means, and how many records there are.
- You can ask AI to generate sample data for you — that is the fastest way to get something to run against in one class. Ask for a small, realistic dataset (say, 20 rows) as a Python list of dictionaries or a small CSV you can paste in. Then look at it: are the values plausible, are there any missing or duplicate entries, does it cover the edge cases your program has to handle? Say in your presentation that the data is AI-generated.
- If it uses no data, say that too, and explain why the problem does not need any.
Step 3 — If You Use AI, Interrogate It
Using AI to write the code is allowed and expected. What is not allowed is presenting code your team does not understand — remember the first rule of this lecture: avoid copy pasting code you cannot explain.
So if AI wrote any part of your program:
- Read every line. Run it. Feed it a weird input and see what breaks.
- Explain how the AI did it — what approach did it take, what data structure did it reach for, and why? Point at the specific lines.
- Ask for a second solution. Prompt the AI for two different approaches to the same problem (for example: "solve this again without using a dictionary" or "give me a second, shorter solution").
- Judge the two. Which one is better, and by what standard — is it shorter, faster, easier to read, easier to change later, or harder to break? Pick one and defend the choice. "They're both fine" is not an answer.
If AI wrote none of it, say so and explain the design decisions you made instead.
Step 4 — Present (2 Minutes)
Two minutes goes fast. Divide the talking among all three of you and cover:
- The problem — what it is and why your team picked it
- The data — what you used, or why none was needed
- The code — walk through the key part, not every line
- The AI — what it generated, how it did it, the two solutions you compared, and which one you kept and why
- The results — run it, or show the output, and say whether it actually solved the problem
What Makes a Good Presentation
- You can explain every line of your program when asked
- Your comparison of the two solutions has a reason behind it, not just a preference
- You are honest about what did not work — a bug you hit and could not fix is a perfectly good thing to present
- All three team members speak