Build Your Own Small Program, Start to Finish
Okay so here's the thing. This is the lesson where we stop practicing pieces and actually build something. Not a huge thing. A small thing that's yours, start to finish, and you can point at it when it's done and say "I made that."
We've covered variables, if statements, loops, breaking problems into stupid-small steps, reading error messages, and backups. That's the whole toolkit for a real first program. You've got everything you need. So let's use it.
Pick something small. Smaller than that.
The number one thing that sinks people at this stage is picking a project that's actually three projects stacked on top of each other. You do not need to build the next great budgeting app. You need to build something that does one useful, boring thing.
Some ideas that are the right size for today:
- A program that asks for a list of grocery items and totals up rough prices
- A program that takes a bunch of numbers and tells you the average
- A little quiz that asks 3 questions and tells you your score
- A program that asks for a name and a few facts and prints out a little bio
Pick one. If you're stuck, pick the grocery one. Every household has this problem and half of you are going to relate to what I'm about to tell you.
Break it down before you type anything
Grab paper. Actual paper, or a sticky note, whatever. Before you write a single line of Python, write out the steps in plain English. For the grocery one it looks something like:
- Ask the user how many items they're buying
- Loop that many times, asking for each item and its price
- Add each price to a running total
- After the loop, print the total
That's it. Four steps. Notice none of those steps are "write the whole program." That's on purpose. If you try to write the whole thing in one shot you will get lost, and then you'll blame yourself instead of blaming the approach, which is the actual problem.
Build it one piece at a time
Write step 1. Run it. Does it ask the question and does it work? Good, move on.
Write step 2, the loop. Run it. Print out what the loop is grabbing each time just to see it happening, even before you do anything with it. This is the print-statement thing I keep bringing up. My son calls it debugging like a caveman. I call it seeing what's actually happening instead of guessing. Both true.
Add the running total. This is where people trip on something small and specific, so let me save you the hour I lost.
I once named a variable list because, well, it was a list. Program broke immediately and I could not figure out why for a good hour. Turns out Python already uses the word list for its own purposes, and naming my variable that stomped all over it. Loud lesson. So when you're naming your running total variable, don't name it total if you're also using a built-in word somewhere, and generally don't reuse Python's own vocabulary for your variable names. Call it grocery_total or running_total or something with your own fingerprint on it. Boring names are safe names.
Type this yourself, by the way. Don't copy it from somewhere and paste it in. Your fingers learn the shape of the code when you type it, your eyes don't learn much of anything when you paste. I'm firm on this one.
Put the pieces together
Once each little chunk works on its own, string them together in order. Run the whole thing. It will probably break somewhere. Good. That's the interesting part, not the failure part. Read the error message slow, like we practiced. It'll usually tell you almost exactly where things went sideways.
Here's my actual opinion on this, since I've got one: clever code is bad code. If you get it working in some slick one-line way you're proud of, and you can't explain it back in plain English, rewrite it boring. I did this to myself once, wrote a real cute one-liner, showed my son, felt smart. Came back to it a week later and could not read my own code. Clear beats clever every single time you'll actually need to touch this again, which is basically always.
Test it like you're trying to break it
Put in weird stuff on purpose. Zero items. A price with letters in it. See what happens. If it breaks, that's not a bad sign, that's you finding the edges of your own program before somebody else does. This is also a good moment to save a copy before you go poking at it, in case you break something you can't easily undo.
Before next time
Finish your small program, even if it's ugly, even if it only sort of works. Bring it next class whether you're proud of it or embarrassed by it. Both are fine. I want to see the broken ones just as much as the clean ones.