Breaking a Problem into Stupid-Small Steps
Okay so here's the thing. You've now got if statements, loops, comparisons, the whole toolbox. And this is exactly where people get stuck. Not because the tools are hard. Because they try to write the whole program in one go, staring at a blank file, trying to solve everything at once.
I want to talk you out of that habit before it forms.
The mistake everybody makes
Somebody comes to me wanting to build, I don't know, a program that tracks their workouts. Reasonable thing to want. And they sit down and try to write the whole thing start to finish in one pass. Input handling, math, formatting the output, saving it somewhere, all at the same time, in their head, before they've typed a single line.
That's like trying to shoot, edit, and deliver a wedding album in one motion without ever looking through the camera first. Nobody does that. You take the picture. You look at it. You take the next one.
Code is the same. You build the smallest possible piece, you check that it works, and then you add the next smallest piece.
Grocery money and cheese
Camille asked me to write something to track our grocery spending after a Costco run got a little out of hand. You know the run. You go in for eggs and paper towels and you leave with a rotisserie chicken the size of a toddler and a flat of protein bars nobody asked for.
I did not sit down and try to write "the whole grocery tracker" that night. I broke it down stupid small. First step: can I get the program to just print one number I type in? That's it. Just prove the input works. Second step: can I add two numbers together and print the total? Third step: can I keep a running total across more than two numbers? Fourth step: can I sort the totals by category?
Each one of those took me maybe ten minutes, because each one only had to do one tiny thing. By the time I stacked them up I had a working program. It told us exactly what we already suspected, which is that we spend an embarrassing amount on cheese. The program worked great. The finding was just depressing. So.
What "stupid small" actually looks like
When I say stupid small, I mean smaller than feels reasonable. Here's a rough process I use on basically everything:
- Say the problem out loud in plain English first. Not code. Just words. "I want to look at a list of numbers and print the biggest one." If you can't say it in a plain sentence, you're not ready to code it yet.
- Find the smallest piece of that sentence you can prove works. Not the whole list. One number. Can you print one number? Yes? Good, that's step one done.
- Add one thing at a time. Now can you print two numbers? Now can you compare two numbers and say which is bigger? Now can you loop through a short list, three items, and do that comparison each time?
- Test after every single addition. Don't write five new lines and then run it. Write one line, run it, see it work, write the next line. Yes, this feels slow. It is faster than it feels, because you catch the broken thing immediately instead of hunting through fifty lines later wondering why the computer hates you today.
- Only then scale it up. Once your three-item list works, try it on the real list of four hundred items. This is the same idea as the file-renaming thing from a few lessons back. Get it right on one file. Then let it loose on four hundred.
My opinion on this, since you asked
You do not need to be good at math to do this well. People assume coding is a math skill and it's mostly not, it's a patience skill. Breaking things into stupid-small steps is basically just being stubborn in an organized way. You don't need to see the whole solution up front. You need to see the next tiny step and be willing to test it before moving on.
A practical way to do this at home
Grab a piece of paper, not the keyboard yet. Write your problem as a plain sentence. Then under it, list every tiny sub-step you can think of, even ones that feel too small to write down, like "get one input from the user" or "print that input back out." If a step still feels big, break it again. You want steps so small they feel almost insulting to write code for. That's the right size.
Then go build them in order, testing each one before you move to the next. Resist the urge to write ahead. I know it's tempting once you're in a groove. Do it anyway.
Before next time
Pick something small and real in your own life, workout log, book list, whatever, and write the plain-English sentence for it plus your list of stupid-small steps. Don't code any of it yet. Just the list. We'll build off it next lesson.