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.
This series is about design process and organizing our thoughts for effective development. The main goal is to establish a mental model and intuition for effective design process. The duck bit will be explained later.
I’ve sat through many a coding interview as both examiner and examinee. The experience is usually sub-par on either side.
Clojure has a unique type system based on specifications: Clojure.spec. The type system includes constraints, and it can automatically test any spec-ed function to ensure valid inputs always produce valid outputs. I think this kind of testing can be brought to statically typed languages to improve test completeness.
I previously wrote about result types and union types in C#. I got to wondering if a union-based approach would allow nicer result types. In short, it works, but not as nicely as I’d hope.
Lambdas, or functions as values, have worked their way into mainstream programming and transformed development for many programmers.
The TestApi pattern helps decouple tests from our system and enables more stable and reusable tests. I’ve shown how I use the pattern in F#. Now here’s a similar example in C#.
I fooled myself for a moment into thinking F# has ad-hoc polymorphism. Interface inheritance in F# looks a lot like traits in rust. So, why doesn’t F# support trait-like polymorphism.
The Great Rewriting in Rust is a good overview of why Rust is a compelling and growing language. However, I have a small quibble with how it refers to F#. The article states F#, Dart, Swift, or Kotlin either, which seem to be more interested in replacing the null keyword with optionals, thereby solving Sir Hoare’s mistake. Sir Hoare’s mistake refers to null. I can’t speak to Dart, Swift, and Kotlin, but I know F# rather well.
Continuous Integration (CI) is a hot buzzword. I’ve had a general sense of it for a while, but Refactoring chapter two brought its place into sharp focus, mainly through Preparatory Refactoring.
Looking for value objects among entity members is one of my favorite lessons from Domain Driven Design. Here’s a quick overview.