Topic index
- Formal methods Specifications, invariants, model checking, and proof-oriented design.
- Programming languages Semantics, type systems, compilation, and compositional reasoning.
- Systems Latency budgets, measurement, failure modes, and performance trade-offs.
Mini-notes
1) Contracts and interfaces
A useful way to think about a component is by its contract: what it assumes about its environment and what it guarantees in return. Even informal contracts help avoid “implicit coupling” where behaviour depends on undocumented side effects.
2) Invariants as debugging tools
Invariants are not only for proofs. Writing down a simple invariant often clarifies what “should never happen” and becomes an immediate source of checks: assertions, property tests, or monitoring rules.
3) Performance budgets
Treat performance like a constraint, not a goal. Decide acceptable bounds (latency, memory, tail behaviour) early and measure against them. A budget makes trade-offs explicit and prevents “accidental complexity” from becoming the default.
4) Composition pitfalls
Composition fails when assumptions don’t compose: two correct components can create an incorrect system if they expect incompatible schedules, resources, or error semantics. Always document concurrency, ordering, and failure behaviour at boundaries.