Skip to content
Utah Community Learning

Materials & extras

Downloads

Handouts, flashcards, and note cards from your instructor. Print any of them.

  • HandoutHandout 1: Supply & Shopping List

    Handout 1: Supply & Shopping List ### Introduction to Coding with Python — Utah Community Learning

    Okay so here's the thing about coding class supplies: it's basically free. That's not a sales pitch, that's just true. If a beginner course tries to sell you software, run. I'll prove it week one.

    Below is everything you actually need, plus a few nice-to-haves if you want to make the experience a little smoother. Budget tier will get you through the whole class just fine.

    ---

    Budget Tier (this is genuinely all you need)

    A laptop or desktop computer. Windows, Mac, or Chromebook, doesn't matter. Mine's an old Subaru-tier laptop that sounds like a jet engine when it's thinking too hard, and it runs everything we're doing just fine. You do not need a fast computer for this. You need a computer that turns on.

    Python itself — free. We'll install this together in class, first thing, so don't stress about doing it ahead of time unless you want to. Download from python.org. That's it. That's the whole cost.

    A text editor — free. We'll use something called VS Code (Visual Studio Code, also free, also from a legit source, not sketchy despite the name). Some other free option works too if you've already got a preference. If you don't, don't worry about it, we'll set it up together.

    A notebook and pen. Not a laptop note, an actual paper notebook. I fill up moleskins with this stuff and there's something about writing code out by hand, even just notes on it, that makes it stick different than typing does. Cheap notebook from Macey's is perfect. Do not buy a fancy one, you'll just feel bad about writing typos in it.

    That's the whole list. Computer, free software, notebook, pen. Total cost: zero dollars, assuming you already own a computer.

    ---

    Nice-to-Have Tier (optional, not required)

    A second monitor, even an old hand-me-down one. Nice for having your code on one screen and instructions on the other. Not required. I taught myself on one screen for two years.

    A mouse, if you're on a laptop and hate the trackpad. Small comfort thing, doesn't affect the coding at all.

    A cheap USB drive for backing up your work. Actually, let me upgrade this one. After my very first script deleted 399 photo files in one go (long story, I'll tell it in lesson one), I back up everything, always, no exceptions. A five-dollar USB drive is basically insurance against a bad day.

    Reading glasses, if you need them for screens. This is not a coding tip, this is a getting-older tip, but here we are.

    ---

    Shopping Notes

    Everything software-related is a free download, so there's no store for that part. For the physical stuff:

    • Notebook and pen: any grocery store or Costco run covers it. Don't overthink it.
    • USB drive: same, or check if you've already got one in a junk drawer somewhere. Most people do.
    • If you're buying a computer just for this class, please don't. Borrow one, use a library computer, or come talk to me. You do not need new hardware for Python.

    One more thing. Bring the computer you'll actually use for the rest of the course, not a loaner for day one only. We do a lot of hands-on typing right from the start, and it helps to be on your own machine so your setup carries over week to week.

    See you in class. Bring curiosity, not a credit card.

  • HandoutHandout 2: Python Cheat Sheet

    Handout 2: Python Cheat Sheet

    Okay so here's the thing, you're not going to memorize all of this and that's fine. I don't have it memorized either. I look stuff up constantly, that's not cheating, that's just the job. Tape this to your monitor or stick it in your bag. Here's the core stuff we use in class, all in one place.

    Printing Stuff (your best debugging friend)

    ``python print("Hello") print(3 + 4) print("Value is:", some_variable) ``

    Print statements are super underrated. When your code's not doing what you think, stick a print in there and see what's actually happening. My son calls this "debugging like a caveman." I don't care. It works.

    Variables

    ``python name = "Taylor" age = 45 is_raining = False ``

    No quotes around numbers or True/False. Quotes around text (we call it a "string"). One heads up from personal experience: don't name a variable list, str, or type. Python already uses those words for its own stuff and it will quietly ruin your afternoon. Ask me how I know.

    Basic Math

    ``python + add - subtract * multiply / divide ** power (2 ** 3 is 8) % remainder (7 % 2 is 1) ``

    You do not need to be good at math to do this class. I mean it. This is basically all the math we touch.

    If/Else (making decisions)

    ``python if age >= 18: print("adult") else: print("not yet") ``

    Watch the colon. Watch the indenting. Python cares about spaces in a way most languages don't, and a stray space or missing colon is a super common way to lose an evening. Speaking from experience there too.

    Loops (doing something over and over)

    ``python for i in range(5): print(i) ``

    ``python count = 0 while count < 5: print(count) count = count + 1 ``

    If a while loop runs forever and your fan starts sounding like my old Subaru of a laptop, you probably forgot to change the counter. Hit Ctrl-C to stop it. That combo has saved me more times than I can count.

    Lists

    ``python photos = ["img1", "img2", "img3"] photos[0] # first item photos.append("img4") len(photos) # how many items ``

    Lists start counting at zero. Everybody trips on this at first. You're not slow, it's just a weird default the whole language agreed on before either of us showed up.

    Functions (packaging up steps you'll reuse)

    ```python def greet(name): print("Hello, " + name)

    greet("Camille") ```

    A few house rules

    • Type it yourself. Don't copy-paste from the slides. Your fingers learn something your eyes skip right past.
    • Break it into stupid-small steps. Don't try to write the whole program at once. Get one photo renamed before you try to rename four hundred. That lesson cost me almost my whole photo library once, we'll get into it.
    • Clear beats clever, every time. If you can't read your own code in a week, it doesn't matter how slick it looked when you wrote it.
    • Save often, back up your files. Just trust me on this one.

    That's the sheet. Bring it to every session. If you lose it, that's fine too, we'll print another one, nobody's grading your paper management here.

  • Worksheet```markdown

    ```markdown # Handout 3: Debugging Checklist (a.k.a. "Figuring Out Why the Computer Hates Me Today")

    Okay so here's the thing. Your code is going to break. Not "might," will. Mine still does, constantly. This isn't a sign you're bad at this, it's the actual job. This handout is what I run through, in order, every single time something goes sideways. Fill it in as we go so you've got your own copy for when you're home alone with a red error message and no Taylor in the room.

    ---

    Step 1: Read the error message. Actually read it.

    Most people's eyes skip straight past the error text to panic. Don't. Somewhere in there is usually a line number and a plain-English complaint.

    • [ ] I found the line number the error is pointing to
    • [ ] I read the actual words of the error, slowly
    • [ ] The error mentions: ________________________________

    Step 2: Check the boring stuff first

    Super common mistake, all of it. I've done every one of these, some of them twice.

    • [ ] Indentation matches (Python cares a lot about this)
    • [ ] Every quote mark has a partner
    • [ ] Every parenthesis has a partner
    • [ ] No extra or missing spaces where they matter
    • [ ] I didn't name a variable something Python already uses (list, str, type — ask me about this one sometime)

    Step 3: Print it out

    This is my whole strategy, so. Not fancy, works great.

    • [ ] I added a print() statement near where it broke
    • [ ] I printed the variable right before the line that fails
    • [ ] The value printed is: ________________________________
    • [ ] Is that what I expected it to be? Y / N

    If it's not what you expected, you just found your bug. That's the heist right there.

    Step 4: Shrink the problem

    Don't try to fix the whole program at once. Comment out chunks until you've got the smallest piece that still breaks.

    • [ ] I removed or commented out code that isn't related to the error
    • [ ] I ran just the small piece by itself
    • [ ] It still breaks / now it works (circle one)

    Step 5: Say it out loud or write it down

    Sounds silly. Works anyway. Explaining your code line by line to a rubber duck, your cat, or me, will surface the problem more than you'd think.

    • [ ] I explained what this line of code is supposed to do, out loud
    • [ ] Saying it out loud made me notice: ________________________________

    Step 6: Look it up. This is not cheating.

    I look up syntax every single time I write code. Every time. I do not have it memorized and I'm not going to pretend otherwise.

    • [ ] I searched the exact error message
    • [ ] I found something that looked like my problem

    ---

    The one rule underneath all of this

    Break the problem into stupid-small steps. Rename one file before you try to rename four hundred. Ask me how I know.

    Notes / what actually fixed it this time

    `` _________________________________________________ _________________________________________________ _________________________________________________ ``

    Keep this sheet. Tape it somewhere near your computer if you want. You'll use it more than you think, and there's no shame in it. At the end of the day debugging isn't a separate skill from coding, it basically IS coding.

  • HandoutHandout 4: When It Breaks (And It Will)

    Handout 4: When It Breaks (And It Will)

    Okay so here's the thing. It's going to break. Not might. Will. Every single person who's ever learned to code, including me with my 400-files-turned-into-1 disaster, has sat there staring at an error message feeling dumb. You're not dumb. The computer is just very, very literal and has zero people skills. Here's the stuff that trips up almost everybody, in the order you'll probably hit it.

    1. "SyntaxError" and you don't know why Usually you're missing a colon at the end of a line (if, for, def all need one), or you forgot a closing parenthesis or quote mark. Read the line the error points to, and also the line right above it. Python's line numbers are a little behind sometimes.

    2. Nothing happens when you run it Check that you actually saved the file. Sounds dumb. Happens constantly. Also check you're running the file you think you're running, not an old copy sitting in another folder.

    3. "NameError: name 'x' is not defined" You used a variable before you created it, or you spelled it differently somewhere (total vs totall). Python doesn't guess what you meant. It just tells you it has no idea what you're talking about.

    4. Indentation errors Python cares, a lot, about spacing at the start of a line. Mixing tabs and spaces will break things in ways that look completely fine to your eyes. Pick one, spaces are the standard, and let your editor auto-indent for you.

    5. It ran, but the output is wrong This is the good kind of broken. Something is happening, it's just not the thing you wanted. Stick a print() statement in the middle of your code to see what a variable actually holds at that point. My son makes fun of me for this constantly. I don't care. It works.

    6. Using a word Python already owns I named a variable list once because it was, in fact, a list. Broke everything downstream and it took me an hour to figure out why. Python has its own reserved words (list, str, type, input, that kind of thing). Avoid naming your stuff the same as Python's built-in words.

    7. An extra space or invisible typo Spent two full hours convinced my code was cursed. It was one extra space. Computers do not forgive whitespace the way people forgive a typo in a text. If everything looks right and it still won't run, retype the line from scratch instead of staring at it harder.

    8. Infinite loop, computer fan screaming If your loop never stops, you probably forgot to update the counter or condition inside it. Ctrl-C is your emergency brake, it stops a running program cold. Learn that key combo now. It has saved me more times than I can count.

    9. Copy-pasted code that "should" work If you copy-pasted it from somewhere, type it out yourself instead. Your fingers catch typos and structure that your eyes skim right past. I'm firm on this one, it's not busywork, it actually builds the muscle.

    10. You don't know what broke, exactly Break your program into the smallest possible piece and run just that piece. Don't try to debug all forty lines at once. Rename one file before you try to rename four hundred of them. Ask me how I know.

    ---

    General rule: read the actual error message, slowly, out loud if you have to. It's not there to embarrass you. It's the computer telling you, in its own weird flat voice, exactly what it needs. Figuring out why the computer hates you today is basically the whole job. Every working programmer does this daily, forever. You're not behind. You're just getting started.

  • podcast_scriptClass podcast — episode 1

    Audio coming soon — show notes below.

    JESS: —okay wait, say that part again, because I don't think I've ever heard the ending of that story.

    TAYLOR: Which part.

    JESS: The 399 files.

    TAYLOR: Oh. Yeah. So. My very first script, the one I wrote to fix my photo-renaming problem, I ran it on a folder of 400 photos from a shoot. It was supposed to rename each one by date. It renamed the first one fine, and then every single file after that got renamed to the exact same name.

    JESS: So they overwrote each other.

    TAYLOR: One by one. Live. I watched it happen and did not understand what I was looking at until it was done. Ended up with one photo and 399 dead files.

    JESS: That's genuinely a nightmare.

    TAYLOR: It's a nightmare if you don't have backups, which, at the time, I did not. That's the actual lesson. Not "coding is scary," it's "back up your stuff before you let a script near it." Now I back up compulsively. Camille thinks I'm paranoid about it.

    JESS: This is Introduction to Coding with Python, session one, for anyone who just tuned in and has no idea why we're talking about deleted vacation photos.

    TAYLOR: Wedding, actually. Client wedding.

    JESS: Oh, worse.

    TAYLOR: Much worse. Anyway. I'm Taylor, I teach the class, I'm a photographer by trade and a coder by pure stubbornness, and Jess makes me do these podcasts every session whether I want to or not.

    JESS: You always want to.

    TAYLOR: I always want to, that's true.

    JESS: So for people deciding whether to sign up. What is this class actually going to feel like. Because I think people hear "coding" and picture math and whiteboards.

    TAYLOR: Yeah, and that's the thing I want to correct right up front. You do not need to be good at math for this. Everyone says that coding is math. It's mostly stubbornness and reading error messages carefully. Math shows up way less than people think it does. What you actually need is patience for being wrong a lot, because you will be wrong a lot, and that's fine. That's most of it.

    JESS: Give me a practical tip. Something somebody listening right now could use even if they never take the class.

    TAYLOR: Okay so here's the thing. If you ever do write any code, even just following a tutorial online, type it yourself. Don't copy and paste it.

    JESS: Why does that matter?

    TAYLOR: Your fingers learn something your eyes don't. I'm serious about this one. When you copy-paste, your brain sort of skims past it, it looks familiar, it feels like you understood it. When you type it out, you notice the parentheses, you notice the colon at the end of the line, you notice the stuff that actually breaks when you get it wrong. It's slower. It's supposed to be slower.

    JESS: That's your one hill.

    TAYLOR: That's one of my hills, I've got a few.

    JESS: Okay, tell me the other story, the one you texted me about, the frozen laptop.

    TAYLOR: Oh, the infinite loop. Yeah. So a loop, if you don't know, is just a chunk of code that repeats. Super useful, super common. And I wrote one where I forgot to change the counter, the thing that tells the loop when to stop. So it just... didn't stop.

    JESS: Forever.

    TAYLOR: Forever. I've got this old laptop, it sounds like a Subaru with 200,000 miles on it, and the fan just started screaming. Full send. And I sat there for a solid minute like, huh, why is my computer having a panic attack, before I realized what I'd done.

    JESS: What'd you do.

    TAYLOR: Ctrl-C. Keyboard shortcut, kills whatever's running in your terminal. That key combo has saved me probably a hundred times since. If you ever end up anywhere near actual code and something's just spinning and spinning, Ctrl-C first, panic second.

    JESS: I love that as a life motto honestly.

    TAYLOR: It's not bad.

    JESS: Alright, so give people the shape of what's coming. Next session, what are we actually doing.

    TAYLOR: Next time everybody's got a laptop open, we get the free tools installed, that's the whole session basically, and by the end of it you type your first actual line of code and get the computer to say something back to you. It's not fancy. It's like, one line. But I've had a room full of adults go a little quiet the first time it works.

    JESS: The gasp lesson.

    TAYLOR: The gasp lesson, yeah, that's a story for another day though.

    JESS: Save it. Alright, that's episode one. Come with a laptop next time, don't come with anxiety about math.

    TAYLOR: Please don't. It's not that kind of class.

  • podcast_scriptClass podcast — episode 2

    Audio coming soon — show notes below.

    JESS: —and that's genuinely the moment I look forward to every session. Okay, we're rolling. This is Utah Community Learning's class podcast, episode two, for Intro to Coding with Python. I'm Jess, I produce this thing, and Taylor's here again.

    TAYLOR: Hey. Sorry, were we already talking? I get going before you hit record, that's a me problem.

    JESS: It's fine, it's a good problem. So last episode was all setup, why Python, why you teach this. Today I want to get into what actually happened in week one with real students.

    TAYLOR: Okay so here's the thing about week one. Nobody believes me when I say the goal is just to get one line of code to run. One. They think I'm being nice about it. I'm not being nice, I'm being accurate.

    JESS: You had them print something.

    TAYLOR: Print "hello," basically. Super simple, one line, print your name or whatever. And there's always at least one person who's convinced it's not going to work. Arms crossed a little. And then it runs and their name shows up on the screen and something happens to their face.

    JESS: This is the gasp story, isn't it.

    TAYLOR: This is the gasp story. Years ago, different class, total beginner, hadn't touched a computer like this in her life. Her program ran and she gasped. Out loud. Loudest gasp I have ever heard over a text file. I've been chasing that reaction ever since, if I'm honest. That's the whole reason I keep doing this instead of just, you know, staying home with my cameras.

    JESS: Did it happen again this time?

    TAYLOR: Not a full gasp. But there was a guy in the back who said "wait, that's it?" in this almost offended voice, like the computer owed him more of a fight. Which, fair. I get that. I felt that exact thing my first Saturday ever doing this.

    JESS: Okay, give the people something they can actually use. Not everybody's in the room with you.

    TAYLOR: Yeah, alright. Here's a free one. If you're ever typing along with a tutorial and something breaks and you don't know why, stick a print statement in the middle of your code. Just print out a variable, see what it actually is versus what you think it is. Nine times out of ten the computer isn't broken, you're just wrong about what's in there. My son thinks this makes me a caveman, uses fancy debugging tools, whatever. Fine. Caveman method's fast and it works and you don't need to install anything.

    JESS: You said last time you learn syntax by looking it up every time, not memorizing it.

    TAYLOR: Every single time. I'm not exaggerating for effect. I forget how to do basic stuff constantly. Looking it up isn't cheating, it's the actual job, that's what the job is. If a student feels dumb for googling something in my class they're doing it exactly as wrong as I do it, so we're even.

    JESS: Any disasters this week? You usually have one.

    TAYLOR: Nothing catastrophic, knock on wood. Somebody named a variable something Python already uses for itself, learned that the loud way, took us a minute to figure out why nothing downstream worked. I've done that exact thing. Named a variable "list" one time because, well, it was a list, seemed logical. Broke everything for an hour. So we bonded over that a little.

    JESS: What's next session?

    TAYLOR: Loops. We're doing loops. This is where it starts feeling less like typing commands and more like actually programming, because suddenly the computer's doing the repetitive thing for you instead of you typing it four hundred times. Bring a problem in your head where you do the same boring task over and over, we'll try to loop it.

    JESS: Any homework between now and then?

    TAYLOR: Just keep the file open. Retype the print line from memory once, don't copy paste it, your fingers need to remember it not just your eyes. That's it. Small step. That's the whole assignment.

    JESS: Taylor, thanks.

    TAYLOR: Yeah, anytime. See everyone next week, and bring coffee, loops take a minute to click for some people and that's fine, that's normal, we go slow.

  • podcast_scriptClass podcast — episode 3

    Audio coming soon — show notes below.

    JESS: —okay wait, say that again, because I don't think I've ever heard someone describe a for-loop as "grocery shopping with a list."

    TAYLOR: It's the easiest way I've got. You've got a list, you go item by item, you do the same thing to each one. Grab it, put it in the cart, next. That's a loop. That's it. That's the whole concept, everything else is decoration.

    JESS: See, that's the kind of thing that would've saved me a headache in high school computer class.

    TAYLOR: Right, they always start with the vocabulary and lose everybody. I start with, okay, what does this actually do in your life. Then the vocabulary sticks because it's got something to hang onto.

    JESS: So this week in class you all got into loops for real.

    TAYLOR: Loops and a little bit of lists, yeah. Which, side note, funny story from way back. One of the very first things I ever learned the hard way was, do not name a variable "list."

    JESS: Why not?

    TAYLOR: Because Python already uses that word for its own thing. It's built in. So I named my list "list," like a genius, and everything downstream just broke. Errors that made no sense to me. I sat there for an hour going, why does the computer hate me today, this should work.

    JESS: And it was just the name.

    TAYLOR: Just the name. I finally figured it out and felt so dumb, and then felt better, because now I never do it again. That's kind of how all of this goes. You get burned once by something small and it's yours forever after that.

    JESS: I feel like every week you've got a "here's the dumb thing that taught me everything" story.

    TAYLOR: I've got a backlog. This job's basically made of them.

    JESS: Okay, give me the practical tip. Something somebody listening at home, not in the class, could actually use tonight.

    TAYLOR: Sure. So here's the thing, if you're ever stuck in a loop that won't stop, like it's just running and running and your laptop fan starts screaming at you, don't panic and don't yank the power cord. Ctrl-C. That's it. Hold control and hit C, it'll interrupt whatever's running and hand you back control of the program.

    JESS: Ctrl-C, I'm writing that down.

    TAYLOR: I've used that key combo probably a hundred times. Usually because I forgot to update a counter somewhere and the loop just goes forever, thinking it's not done yet. It's not a crisis. It's just the computer doing exactly what you told it to do, which is sometimes the problem.

    JESS: That feels like it should be on a poster somewhere. "It's doing what you told it to."

    TAYLOR: Ninety percent of debugging, honestly. The computer's not being difficult. You were just unclear.

    JESS: Harsh but fair.

    TAYLOR: I say it to myself more than anybody.

    JESS: Okay, one more thing before I let you go. What's coming up next session, give people a reason to show up.

    TAYLOR: Next time we start writing our own functions. Which sounds fancy but really it's just, instead of writing the same five lines over and over, you write it once, give it a name, and call it whenever you need it. Like a little machine you built that you can just plug in.

    JESS: Is this the part where things start feeling like real programs?

    TAYLOR: This is exactly that part. This is where it clicks for a lot of people. Somebody in an earlier session, first time she got her own little program running, she actually gasped out loud. Loudest gasp I've ever heard over a text file on a screen. That's the moment we're building toward with functions. Everything starts feeling less like copying steps and more like you're actually building something.

    JESS: I love that you remember that gasp.

    TAYLOR: That's the whole reason I keep doing this class. So.

    JESS: Alright. Next session, functions, bring your laptop and your patience.

    TAYLOR: And type it yourself. Don't copy-paste. Your fingers gotta learn it too.

    JESS: Every episode, that rule.

    TAYLOR: Every episode, because it's true every time.

Videos worth your time

Hand-picked by your instructor, with notes on what to watch for.

Practice corner

6 quizzes and 2 games. Playable by anyone, no account needed.

Open the practice corner →