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.
I’ve found that curiosity drives outcomes for many leadership skills in one actionable concept.
There are many ways to modularize a system. I initially learned Volatility-based Decomposition. I now speak in more Domain-Driven Design terms. However, I consider this a change in framing more than a change in strategy.
Scaling Architecture Conversationally clearly and concisely explains how and why architecture is more of a facilitated process than a top-down decision process.
I’ve been using a Socratic approach to promote critical thinking, but it appears to promote good leadership habits as well.
The Single Responsibility Principle applies even to identifying sub-domains.
I’ve been learning Scala lately, and it turns out that scala union types are sometimes implemented the same way I discovered unions could be imitated in C#.
I rarely worry about constructors or initialization in F#. But, every once in a while, the difference is important.
In short, I’ve been using F# for several years now and didn’t realize that F# record types can’t be inherited. I think this demonstrates that inheritance for data types is unnecessary when actions and data are separated, and it may hint at a larger trend in programming languages.
This post recounts my journey to understand tests data arrangement from before my blogging days. This exploration cemented key lessons in reusability and composition.
Sports generally have some fundamental skills that athletes drill endlessly. These fundamentals are the foundation for good execution. They must be committed to muscle memory if the athlete wants to focus on higher-level skills and strategy. In fencing, footwork is fundamental. What is the equivalent for software?