Day 1: Bricks Before Blueprints
Day 1: Bricks Before Blueprints
Before today, I could describe how a program works. I could tell you what a variable is, roughly what a loop does, why functions exist. I had the vocabulary. What I didn't have was the muscle memory. The ability to open a blank file and just build something without a scaffold already in place.
That's what today was about.
What I actually built
10 scripts and one real project, all from a blank file, no AI writing the code.
The scripts were small by design, each one targeting a single concept: f-strings, type inspection, comparison operators, unit conversion, control flow. Nothing impressive on its own. The point wasn't the output, it was the repetition of the loop: write → run → see what happens → fix it.
The project was a number guessing game. Computer picks a random number between 1 and 100, you guess, it tells you higher or lower, loops until you get it right, then tells you how many guesses it took. Four moving parts working together: a random number, a loop, branching logic inside the loop, a counter persisting across iterations.
First real program. Fully mine.
Where I got stuck
The input type bug. I forgot that input() always returns
a string, not a number. So when I tried to do math on what
the user typed, Python threw a TypeError. Took about 5 minutes
to remember you have to explicitly convert it:
int(input("Number: ")). Small thing, but it's the kind of
thing you only really remember after hitting it yourself.
What I reached for that I wasn't told to use
Error handling. The spec given to me for the guessing game didn't mention
what to do if someone typed a letter instead of a number.
I knew that would crash the program, so I looked up how to
handle it try/except ValueError and figured out how
to use it myself. When it worked, that felt like the first
moment today where I wasn't following instructions, I was
solving a problem.
What I understand now that I didn't this morning
Two things that sound simple but aren't when you first encounter them:
Variables are labels, not boxes. When you write x = 5,
you're not creating a box called x and putting 5 in it.
You're creating a box somewhere in memory and sticking a
label called x on it. The difference matters the moment
you do this:
a = [1, 2, 3]
b = a
b.append(4)
print(a) # [1, 2, 3, 4]
b = a didn't copy the list. It put a second label on the
same box. So modifying through b changed what a sees too.
That one took a minute to sit with.
Catching errors is something you control. Instead of
letting the program crash when a user does something
unexpected, you can wrap the risky code in a try block
and define exactly what happens when it fails. The program
stays alive. You decide what comes next. That shift from
"the program breaks" to "I handle what happens when it breaks". Is a small but real change in how I think about writing code.
Tomorrow: FizzBuzz and a calculator. Both sound simple. I expect at least one of them to take longer than it should.