Module 02: Programming Model

Understand the small set of programming ideas that power most production code.

Programs transform input into output, sometimes changing the outside world.

input -> parse -> validate -> decide -> transform -> store/respond

Most programming is combining:

• Values.
• Data shapes.
• Functions.
• Control flow.
• Modules.
• Errors.
• Side effects.

A program is like a kitchen recipe.

• Ingredients are input data.
• The recipe steps are control flow.
• Tools are functions.
• The kitchen layout is module structure.
• Food safety rules are validation.
• Burnt food is an error.
• Serving the dish is a side effect.

raw request
  -> parse JSON
  -> validate required fields
  -> check user permission
  -> create domain object
  -> save to database
  -> return response

Beginner code:

• Mixes input parsing, rules, storage, and output in one place.
• Trusts input.
• Ignores errors.
• Has no tests.
• Works only for the happy path.

Useful code:

• Separates responsibilities.
• Validates boundaries.
• Names concepts clearly.
• Handles expected failures.
• Has tests for important behavior.

Build a CLI task tracker:

task add "Call customer"
task list
task done 1

Separate it into:

• CLI parsing.
• Task logic.
• Storage.
• Display formatting.

• Adding a task creates an open task.
• Marking a task done changes only that task.
• Empty title is rejected.
• Unknown task ID returns a clear error.
• Corrupted storage file is handled intentionally.

Ask an agent:

Review this task tracker for mixed responsibilities, missing validation,
untested behavior, and unclear names. Suggest improvements without rewriting
the whole program.

• Which functions are pure?
• Which functions have side effects?
• Where is input validated?
• Where are errors converted into user messages?
• What data shape represents a task?
• What behavior should be tested first?

1. Create the task tracker.
2. Write a data shape for tasks.
3. Write task logic without file I/O first.
4. Add tests for logic.
5. Add file storage.
6. Add CLI parsing.
7. Break the storage file and handle the error.
8. Write programming-model.md explaining the flow.

• You can run the CLI from a terminal.
• Tests pass.
• Bad input gives a useful error.
• You can explain pure logic versus side effects.