For updates, sign up here:

Part I: Practical Contextual Math

- 1. Introduction: How Math fits in to Programming
- 2. Arithmetic, Algorithms, and Numbers
- 3. Not Financial Advice

Part II: Basics of Math for Programming

- 4. Program Execution and Math Analogs
- 5. Programming Structures and Math Analogs
- 6. A few Bits about Architecture

Part III: Growing and Showing Software with Math

- 7. Scaling Programs with Math
- 8. Managing Projects with Math: Estimation, Predictions, and Visualization
- 9. Showing off: Promoting and selling
- 10. Keeping and Sharing Secrets

Part IV: Architectural Sophistication

- 11. Functional Programming I: Compositional Programs
- 12. Functional Programming II: Algebraic Architecture
- 13. Guarantees Through Tests, Types, and Proofs

Part V: Games

- 14. Games I: Up to 2.5 Dimensions
- 15. Games II: 3 Dimensions

Part VI: Machine Learning

- 16. Machine Learning
- 17. Projects

Here is some of the information that I discuss and demonstrate in the book. I don't claim these to be *original discoveries*
so much as ones that I feel deserve more engagement relative to tooling concerns which dominate so much of our time.

- Confidence in code is informed by trust, along with experience and choice of guarantees in the program.
- A standard of confidence in a given program can be decided upon by its context and purpose.
- Abstract Algebra can help determine the cardinality of inputs and outputs of your program (the "surface area of testing").
- Abstract Algebra can help identify UX features to adopt or anticipate.
- Category theory can give functional programming a good basis of understanding language and framework features.
- Empathy : Testing :: Representation : Types
- Guarantees ⊆ Possibilities ⊆ Ambitions ⊆ Imagination
- A test is a direct proof.
- A well formed error message provides the basis for a contrapositive proof.
- A characterization test is a proof by contradiction
- Inductive data types provide the basis for inductive proofs.
- A weakness of proofs via types vs tests is the ability to refactor implementation code without breaking guarantees. In other words, tests shouldn't break unless your interface changes, but proofs likely rely on implementation details.

(work in progress)