I’ve been thinking of ways I can encourage students to get knowledge out of their head and experiment. Both so I can give feedback and to get them in the habit of checking their own understanding. I think unit tests might be an effective tool.

A previous post got me thinking about how principles can be measured and what value such measures could provide.

SMART is a set of criteria for setting effective goals. I recently saw a recommendation that architecture principles should be SMART, but I’m not convinced.

I previously enumerated a set of properties that underlay self-documenting code. Is there really a need for another set of properties?

I’ve been pondering properties of self-documenting code. Comparing self-documenting properties against SOLID lead me to realize Information Hiding, or conceptual scope, is a central theme of SOLID.

This series explores the scalability benefits of pure domains. This post explores downsides of pure domains and concludes the series.

This series explores the scalability benefits of pure domains. This post explores how pure domains reduce the rigidity of request and response timing and structure, enabling more control over our API experience.

This series explores the scalability benefits of pure domains. In this post we explore how pure domains enable sophisticated concurrency rules without modifying the domain.

This series explores the scalability benefits of pure domains. This post explores how pure domains mesh well with common system tools: async messaging, logging, and caching.

This series explores the scalability benefits of pure domains. This post introduces important terms and ideas with some examples.