Correctness & Quality
Software that stays correct as it grows: prove behaviour with tests and catch mistakes with types, so mocking, property-based testing and mypy turn 'it works on my machine' into a gate that holds.
"It works on my machine" is not a claim about software; it is a claim about one machine, at one moment, on the inputs someone happened to try. This domain replaces it with two mechanisms that make correctness checkable by something other than hope — tests, which prove behaviour on cases, and types, which prove properties over all cases the checker can see. Neither subsumes the other, which is why both pillars are here and why they close on a shared capstone.
Testing comes first, built from the inside out. You rebuild pytest's core rather
than memorising its API, then face the two judgement calls that separate a
useful suite from a brittle one: what to double — only the boundaries you do not
own, network and time and payments, never your own logic — and what coverage
actually measures, which is which lines ran, never whether you checked what
they did. Property-based testing then inverts the whole activity: instead of
choosing examples, you state an invariant and let a generator hunt for a
counterexample, then shrink it to the smallest input that still fails. Typing
follows as the other half: annotations a checker verifies in CI, Optional
forcing you to handle the missing case, error handling designed as deliberately
as a type hierarchy, and lint rules as a codified team contract rather than an
argument reopened on every pull request.