Critical developer skills in 5 minutes or less.
Half my own learning journey, half experiment to improve software education. These posts attempt to extract best practices from, and connect readers to, leading software literature.
Mental models are foundational. They decide how we interpret information and reason about a topic. Yet mental models for writing software are immature and little discussed. Code That Fits in Your Head puts mental models front and center.
Code That Fits in Your Head collects the myriad of somthing-driven practices into a category of drivers. Drivers create a toolkit for highlighting motivations and responding to them with code.
Code That Fits in Your Head tackles a problem dear to my heart. Mark Seemann realized good software engineering practices are out there, but it’s hard to connect the dots between scattered sources.
Following software to it’s orgins with Alan Turing reveals some interesting trends in how ideas cycle.
Type-driven and Domain-driven approaches commonly represent constrained values with a type. This approach is good, but generally leaves the constraints buried in functions. FsSpec exposes those constraints as data so they can be programmatically understood for validation, data generation, and more.
Sometimes performance is an observable domain behavior that belongs in our normal test suite
Stable, incremental, and additive is my personal theory about what underlies effective software practices. I’m pleased to find these qualities hold up quite well for practices described by Code That Fits in Your Head.
Programmers often arrange boolean expressions in all kinds of groupings for readability. The semantic of these groups, however, is not readily apparent to programs and algorithms. It turns out we can have it both ways, boolean expressions can be algorithmically normalized to consistent depth and form.
I recently learned of dependent type systems. I’m trying to feel out the boundaries of dependent types and came to the question: Is Clojure Spec a dependent type system?
I’ve been thinking about constrained values, and how those constraints could be used to better test our systems. Mark Seemann was gracious to think through this with me and point out some interesting conclusions.