The Cycles of TDD by Robert Martin is the most wholistic explanation of TDD I’ve read. It helped me to put the pieces together and understand how TDD can drive a good design process from end-to-end. Here’s an attempt to visualize it.

I once worked for a company that exposed all of their entities IDs as integers. It’s common practice, but it bit them hard when they needed to adopt an offline-then-merge strategy for client data. This required switching ids to Guids all over the code base and it was an arduous undertaking. I’ve been trying and failing to simply abstract ID types since.

I want to cleanly represent predictable failure states as part of my function contracts. This lets consumers know right away what scenarios they should expect without documentation or looking through code. F# encourages this pattern and normalizes it with the Result type. Representing the same idea in C#, however, is non-trivial.

Sometimes a constructor or function can naturally accept multiple types. The classic solution to this is overloading. The problem is overloading can combinatorially expand for every multi-typed parameter.

Aspect-Oriented programming has captivated my imagination for years. C#, however, does not support AOP. Even conceptually realizing benefits of the paradigm proved difficult. Then, I experienced functional composition.

Service-Oriented Programming is my primary programming paradigm. It divides the software into self-contained “services” or groups of functionality. Services also apply in functional programming, rather, service-like behavior is enforced all the way to the foundational functional concepts.

The Pragmatic Programmer tells the now legendary tale of talking with a rubber duck to overcome programming problems. This sounds a bit silly, but programming is a design activity all the way down to the source code implementations. Problems and possibilities often won’t reveal themselves until we try to communicate them. Every programmer needs a duck. So what is yours?

Language is strongly related to the kinds of thoughts we have. Language shapes to favor what it’s users most want to describe. This post introduces a series about how I internalized the value of different programming languages. Specifically, my transition to functional-style thinking. I’ll be diving into concrete design problems and how FP trivialized my long-standing struggle with them.

I posted about Synthesizing Project Organization Methods a few months ago. Well… I’ve been busy putting it to practice in my own code, and the results have been been beyond my expectations!

I’ve been unhappy with the async/background work model in my system for a while. The async logic always seems excessively complex, either entangled with business logic or creating opaque coupling between flows. However, my recent breakthrough on code structure suggested a clear path to adding background work in an aspect-oriented style. Let’s examine a refactor that helped me prove decorator-style async communication.