Contract first
Define inputs, outputs, errors and invariants before designing classes.
Build-it-yourself method
Turn unfamiliar code into a system you understand.
Use one repeatable method: state the contract, build a small core, and test the properties that matter.
A small correct core
Implement one useful behavior with one explicit failure policy.
Visible state
Make ownership and state transitions easy to follow.
Explicit boundaries
Put cancellation, size limits and timeouts in the contract.
Test properties
Check ordering, determinism, resource cleanup and round trips.
Earn abstractions
Generalize when concrete implementations demonstrate the need.
Before calling an experiment finished
- Does its public entry point build?
- Does importing it leave the environment alone?
- Do real tests cover its documented core and error paths?
- Are resources released and input sizes bounded?
- Do examples and both language editions match the implementation?
- Are unsupported integrations and next steps explicit?
What does “finished” mean?
A concept explains an idea. A working experiment demonstrates a tested, documented core. A production package additionally needs compatibility guarantees, operational limits, integration evidence, and maintenance. No badge alone promises production readiness.