Module 00: Orientation

Understand what software engineering work actually is before touching tools.

Software engineering is controlled change to a living system.

user pain -> system understanding -> small change -> verification -> release -> observation

The beginner thinks: “I need to write code.”

The engineer thinks: “I need to change behavior safely.”

Imagine a city. Code is not the city. Code is the blueprint plus instructions for parts of the city. The real city also includes traffic, water, electricity, laws, people, repairs, emergencies, budgets, and bad weather.

Software is the same. Source code matters, but so do data, users, configuration, network, secrets, logs, deployment, cost, and failure.

• A product is the thing users experience.
• An application is software that supports the product.
• A service is a running component with a responsibility.
• A system is all components and people involved in the outcome.
• A feature is a user-visible behavior backed by code, data, and operations.
• A bug is a gap between expected and actual behavior.
• Verification is evidence that behavior is correct.

They do not immediately code. They ask:

• Who is the user?
• What are they trying to do?
• What currently happens?
• What should happen instead?
• Where in the system does this behavior live?
• What data is involved?
• What can fail?
• How will I prove the change works?

Pick one familiar app: food delivery, banking, WhatsApp, email, ecommerce, or college portal.

Draw:

user -> screen -> server -> database -> notification/payment/external system

Then write:

• One user action.
• One piece of data created.
• One backend rule.
• One failure mode.
• One log line you would want if it failed.

Ask an agent:

Explain the system behind a food delivery app at beginner level. Include
frontend, backend, database, APIs, queues, external services, and failure modes.
Then quiz me with 10 questions.

Do not accept the answer blindly. Compare it against your own diagram.

• Why is code alone not the full system?
• What is the difference between a feature and a component?
• Why does a real change need verification?
• What is one example of data that must never be lost?
• What is one example of a failure users can tolerate?
• What is one example of a failure users cannot tolerate?

1. Create portfolio/00-orientation/system-map.md.
2. Draw a system map for one real app.
3. Write one user story.
4. Write the expected behavior.
5. Write three possible failures.
6. Write how you would detect each failure.
7. Ask an agent to critique the map.
8. Revise the map.

• You can explain software as a running system, not only as code.
• You can draw a basic user-to-data flow.
• You can name at least three failure modes.
• You can explain what evidence would prove a fix.