Day 6 — How Software Gets Made
Time: ~50 min · Date: Thu Apr 30
Why this matters
You don't need to write code to use Claude Code. But understanding how software gets built will:
- Help you understand why Claude does certain things (like asking before changing files)
- Make conversations with Chris (or any developer) less mysterious
- Give you a mental model for breaking down work into steps Claude can actually do
This is a tour, not a class. We're skimming the shape of the thing.
The lifecycle
There's an industry term — SDLC, Software Development Life Cycle — but the idea is simpler than the acronym suggests. Software gets built in a loop:
1. PLAN → 2. WRITE → 3. TEST → 4. SHIP → 5. ITERATE
↑ │
└───────────────────────────────────────┘
1. Plan
Decide what you want before writing it. "We want a button that emails the listing to the buyer when clicked."
This includes:
- What problem are we solving?
- Who is this for?
- What does "done" look like?
- What could go wrong?
This is the most underrated step. Bad planning → wasted writing.
2. Write
Actually write the code. This is what most people picture when they think "software development."
In practice it's like writing a long, very precise instruction manual that the computer will follow literally. No nuance. No reading between lines. Forget a comma, get an error.
3. Test
Run the code. See if it does what you wanted.
Two flavors:
- Manual — click the button. Did the email send?
- Automated — write a separate small program that runs your code and checks "yes, it sent the email." Now every future change can be re-tested in seconds.
Real software has hundreds or thousands of automated tests. They're how you know you didn't accidentally break something while fixing something else.
4. Ship
Get it in front of users. For a website, this is "deploy" — push the code to servers where the public can hit it.
Modern shipping happens dozens of times per day at big companies. Tiny changes, frequent releases, easy to roll back if something breaks.
5. Iterate
Watch what happens. Fix bugs. Hear feedback. Make it better. Loop back to step 1.
Software is never "done." It's continuously maintained, updated, expanded. The version of any app you're using today is different from a year ago. The companies behind it are constantly in steps 2–5.
Where the bugs come from
Bugs are not a sign that someone is bad at their job. They're inevitable for two reasons:
- Software is complicated. A modern app has thousands of files, millions of lines. The interactions multiply. No human keeps it all in their head.
- The world changes. A change in one corner can ripple. A library updates, an API changes, a user does something unexpected, and suddenly something that worked yesterday doesn't.
This is why testing matters and why version control (next concept) exists.
Version control: a quick taste
Imagine you're editing a Word doc. You save versions: Listing-Description-v1.doc, Listing-Description-v2.doc, Listing-Description-final.doc, Listing-Description-final-USE-THIS-ONE.doc.
That's manual versioning, and it's a mess.
Git is software for doing this automatically and at scale. Every time you commit a change, git remembers:
- What changed
- Who changed it
- When
- A short message about why
You can roll back, branch off to try ideas without breaking the main version, and merge work from multiple people.
You'll see git phrases like commit, push, pull, branch. We'll cover the bare minimum on Day 9. For now, the mental model is: git is "track changes" for code, on steroids.
Where AI fits in
You'll be doing a kind of software development with Claude — but a lighter version.
Your typical loop will look like:
- Plan: tell Claude what you want.
- Write: Claude writes a draft (of code, content, an email — same loop).
- Test: you read it, try it, see if it does the thing.
- Ship: send the email, save the file, post the listing.
- Iterate: ask Claude to change it. Repeat.
The point isn't to make you a developer. It's to recognize that good work happens in loops, not in one-shot demands. People who try to get a perfect answer from AI on the first try are doing it wrong. People who iterate quickly get great results.
A small but important truth
Most "AI failures" are skipping step 1 (plan) or step 3 (test).
- "I asked AI to write me an email and it was wrong." → Did you give it the right context? (Plan.)
- "I asked AI to summarize this contract and it missed something." → Did you read the summary against the original? (Test.)
When something goes wrong with AI, ask yourself: did I plan well enough? did I check the output?
Exercise (~30 min)
Read this short article (10–15 min):
How GitHub Copilot Works (and Why It Matters) — or any 1000-word article on "AI-assisted coding for non-developers."
Then answer (in your own words, in your notes):
- What's the difference between writing code and shipping code?
- Why do bugs happen — even with experienced developers?
- What part of the SDLC do you think is most likely to be skipped when someone is in a hurry? Why?
- What's one thing in your real estate work that has its own kind of "lifecycle" similar to plan → write → test → ship?
Recap
You should now be able to:
- Name the five steps of the SDLC loop
- Explain why software is "never done"
- Describe what version control / git is for in 1–2 sentences
- Identify where AI helps in the lifecycle (and where it doesn't replace human judgment)
Going deeper (optional, ~45 min)
Watch (~25 min)
- Search YouTube: "Fireship Git in 100 Seconds" — Fireship's "in 100 seconds" videos are one-minute genius. Watch their git, github, and SDLC ones. ~5 minutes total, surprisingly dense.
- Search YouTube: "software development life cycle explained" — pick a 10–15 min video that's not aimed at corporate trainees.
Read (~20 min)
- GitHub Docs — Hello World — official, beginner-friendly. You don't need to do the steps yet — just read what GitHub thinks "getting started" means.
- Atlassian — What is version control? — clean explainer of why this matters.
Done?
- Day 6 complete