This "blog" is an experiment in teaching core skills to be a "10x developer". 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. This post explores the key questions “What is programming?”, “What is Software Engineering?”, and how these answers relate to our design process.
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.
The results always feel incomplete, and the assessment of skill feels foggy and inconsistent. My recent experiments suggest a new approach that may be more effective: defect detection in code samples.
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.