Software engineering: applied workshop

Variables, conditions and loops

Use variables, conditions and loops to make decisions inspectable.

Write a small numeric summary program that handles empty input.

Teaching example: An empty list cannot be averaged by dividing by its length.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Data structures and complexity

Use data structures and complexity to make decisions inspectable.

Compare lists and dictionaries for lookup tasks.

Teaching example: A dictionary is useful for lookups by unique ID.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Git and collaboration

Use git and collaboration to make decisions inspectable.

Practise changes, diff review, commits and branches.

Teaching example: Inspect the diff before committing unrelated changes.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Debugging and reproduction

Use debugging and reproduction to make decisions inspectable.

Describe input, expected/actual result and reproduction steps for a bug.

Teaching example: A minimal failing input is more useful than “sometimes broken”.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Testing and edge cases

Use testing and edge cases to make decisions inspectable.

Design normal, empty, boundary and invalid-input tests.

Teaching example: An absolute-value function needs negative, zero and positive tests.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Interfaces and error handling

Use interfaces and error handling to make decisions inspectable.

Define inputs, outputs and failures for one function or API.

Teaching example: Invalid input should be distinguishable from system failure.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Small project and README

Use small project and readme to make decisions inspectable.

Build a small tool with setup, tests and limitations.

Teaching example: Verify README commands in a clean environment.. Predict the result, independently check the key step, and compare these assumptions with the actual role. Do not use demonstration results as real-world advice.

Worked example · fictional

From a problem to inspectable work

Synthetic balance 100: E1 adds 20, retry E1 adds 20, E2 subtracts five; each event must take effect once.

1. Apply E1 once: 100+20−5=115. Also test concurrency and failure retries, not just this sequential example.
2. Further judgment: Is checking for an event before writing sufficient for concurrent idempotency?
3. No; enforce atomicity, uniqueness and transaction boundaries

Deliver small tool readme and test log: the calculation reference is 115; the recommendation must respect No; enforce atomicity, uniqueness and transaction boundaries. Separate numbers, inference and unknowns.

Failure case and repair

In Debugging and reproduction, copy tool output without definitions, then retain the conclusion when asked: Is checking for an event before writing sufficient for concurrent idempotency?

Even a result of 115 does not explain when No; enforce atomicity, uniqueness and transaction boundaries is supported.

Apply E1 once: 100+20−5=115. Also test concurrency and failure retries, not just this sequential example. Then test assumptions in Interfaces and error handling.