The Developer Workflow

Core path: 30 minutes

What does a programmer actually do between an idea and a working program?

There is a version of programming that exists mostly in movies: type extremely fast, stare intensely at several windows, hit Enter, done.

Hackers is a great movie. It is not a reliable software-development methodology.

Real development is usually less dramatic and much more repeatable.

You make a small change. You run it. You inspect what happened. You decide what the evidence means. Then you change one thing and try again.

The loop matters more than speed.

A working program is built through comparisons

Suppose you want this output:

SYSTEM START
SYSTEM READY

You write:

print("SYSTEM START")
print("SYSTEM REAdY")

The program runs. There is no crash.

It is still wrong.

Expected:

SYSTEM READY

Actual:

SYSTEM REAdY

Run the exact mismatch, then repair only the line responsible for the wrong output:

Run the code to see output.

That comparison gives you something useful. The program does not have a mysterious "coding problem." One output line does not match the requirement. You can now inspect the source responsible for that exact line.

This habit scales surprisingly well:

• requirement versus implementation;
• expected output versus actual output;
• working version versus broken version;
• test expectation versus test result;
• approved file list versus files an agent actually changed.

The tools get more advanced later. The reasoning does not change much.

One controlled change beats five guesses

Imagine the program stops working and you immediately change:

• the file name;
• two lines of code;
• the terminal command;
• the folder;
• and a setting in the editor.

Then it works.

What fixed it?

You have no idea.

That is the problem with random troubleshooting. Movement is not the same thing as progress.

A stronger workflow is boring on purpose:

1. Identify what you expected.
2. Observe what actually happened.
3. Pick one reasonable next check or change.
4. Run again.
5. Compare again.

The boring part is what makes the result explainable.

Your tools are different layers

Professional programming uses more than a programming language. During this course you will work with several tools that solve different problems:

Tool map

A developer works across several tools

Python is only one part of the environment. Each tool owns a different job, and professional work moves between them constantly.

Editor

VS Code

Write, read, search, and organize project files.

Language + runtime

Python

Express instructions and execute them with the Python interpreter.

Command surface

Terminal

Launch programs and work with the project from the command line.

Local history

Git

Record meaningful checkpoints and inspect how the project changes.

Remote repository

GitHub

Synchronize and review a remote copy of the project intentionally.

Optional helper

AI assistant

Suggest or explain work, while the human still owns verification and understanding.

Do not memorize that entire tool map today. Read it as a set of responsibilities.

VS Code or another editor helps you create and inspect source files.

Python provides the language and runtime we are using to execute Python programs.

The terminal gives you a command surface for launching programs and development tools.

Git records local project history.

GitHub can host and share a remote Git repository.

AI assistants can propose or explain code, but a proposal is not evidence that the program works.

Week 2 slows down and teaches the development environment properly. For now, the important point is that these are separate layers. When something breaks, asking "which layer am I actually looking at?" is a much better starting question than "why is the computer broken?"

Your first development loop

Create or open hello.py and use this starting version:

print("Hello")

Run it.

Now stop and record the actual output before changing anything.

Change the source to:

print("Hello, developer")

Run it again.

What changed?

The interpreter did not become a different interpreter. The terminal did not become a different terminal. The behavior changed because the source code changed.

Now make one deliberate mistake:

print("Hello, developer"

Run it and read the error before fixing it.

That sequence—working version, controlled change, new evidence—is the beginning of a professional habit.

When "it works" is not enough

Suppose a classmate says:

I fixed it.

That statement is incomplete.

A useful explanation sounds more like:

The program failed after I removed the closing parenthesis from the print() call. Python reported a syntax problem at that statement. I restored the parenthesis, ran the same command again, and the expected output returned.

The second explanation contains a change, evidence, and a verification step.

That is what makes it defensible.

By the end of this course, you will use that same mindset with tests, APIs, Git history, architecture, and AI-generated changes. Week 1 is just the smallest possible version of it.