The Programmer's Mindset
Computers are brutally literal — and understanding that changes everything
Before you write a single command, there's something more important to understand: how computers think — and why it's completely different from how humans communicate. This difference explains why version control exists, and why learning it feels strange at first.
The sandwich story
Imagine you ask someone to make you a peanut butter sandwich. They put the bread on the counter, open the jar, and stare at you waiting. You say "spread the peanut butter." They put the knife flat on top of the closed jar and stare again. You meant: open the jar, take out some peanut butter with the knife, and spread it on the bread. They did exactly what you said.
This is how computers work
A computer — and by extension Git — does exactly what you tell it. Not what you mean. Not what seems obvious. Exactly what you typed. "git add ." means "stage every changed file in this folder." Not "stage the important ones." Not "stage the ones I've been working on today." Every. Changed. File.
Why this matters for Git
- git add . stages everything — including that .env file with your passwords — If you haven't set up .gitignore, Git will happily commit your API keys to a public repo.
- git reset --hard deletes your work permanently — Git doesn't ask "are you sure?" It does what you said. --hard means discard. Gone.
- git push doesn't ask for confirmation — You push. It pushes. If main has a broken build, your team now has a broken build.
- Commit messages are permanent — "asdfg" is now the official record of what you changed at 11pm last Tuesday.
The programmer's mental shift
Good programmers — and good Git users — learn to think like the computer before they type. Not instead of thinking like a human. As well as. This means:
- Be explicit, not implicit — Don't rely on "it'll probably work." State exactly what you want. Run git status before git add.
- Think in steps — Break everything into the smallest possible actions. Don't think "commit my changes." Think: what files changed? Which ones are relevant to this feature? What did I change and why? Now write the message.
- Verify before you commit — git diff shows you exactly what you're about to save. Read it. Like a chef tasting before serving.
- Undo is not automatic — but it is available — Computers don't forget unless you tell them to. Git keeps everything unless you explicitly delete it. The safety net is there — but you have to use it consciously.
The habit that saves you
Before every git add . or git commit, run git status. Read what it says. Make sure it matches your intention. This 5-second habit prevents 90% of Git mistakes. It's the equivalent of reading your sandwich instructions out loud before you start.
How this connects to version control
Version control forces you to be explicit about your work in a way most other tools don't. When you commit, you're making a deliberate statement: "This is a known-good state. I'm naming it. I'm describing it. Future me can come back here."
Git as a formal decision log
Think of commits like minutes of a meeting — a formal record of what was decided, when, and why. Not a stream-of-consciousness draft. Each commit says "at this moment, I intentionally chose to save the project in this state, and I'm calling it this." That intentionality is what makes version control powerful.
Try this
Before the next lesson, think of something you do regularly — making coffee, getting ready in the morning, planning a trip. Try to write it out as explicit, numbered, unambiguous instructions that a robot could follow without asking any questions. Notice how much you assumed the reader would "just know." That gap between assumed and explicit — that's the programmer's mindset gap.