I’ve been experimenting with adding a feature to the .NET SDK. Oof, this project is understandably large and complex. Here are a few lessons I’ve learned that simplify working on the project.

I recently read Mark Seemann’s post on how Testability is the Open-Closed Principle. This helped me realize the approach to testing directs the kinds of flexibility in our system, and behavior-based testing pushes the right kind of flexibility.

I previously wrote on how acceptance tests can streamline communication between developers and teams. I’ve been thinking about practical enactment of such a scheme and surfaced some interesting ideas.

I’ve been exploring large-scale formal development practices, and realized acceptance tests may be the best way for developers to encode expectations for other developers.

Scott Wlaschin posted an incredible series on dependency injection. It clarifies the different techniques and cases where each is useful. I noticed an interesting relationship between the techniques and the layers I use to categorize services.

Scott Wlaschin wrote a delightful series on dependency injection patterns. Part 4 covers the Interpreter pattern. Interestingly, my main takeaway was that Interpreter is really the same as State Machine.

I previously wrote on the Test API behavioral testing in F#. More time and thinking has brought about a few key improvements, making the pattern both more concise and standardized.

Naming is one of the most important activities in programming. Names are the primary vehicle for communicating intent and making code understandable. Names haves some sneaky counterparts: scope and context. I argue that our tools for scope and context impact how good our naming can be, and file-based modules force coupling between concerns that inhibit global name organization.

I’ve spent most of this year in Clojure after years of .NET. Much of my F# design skills made the jump, but one language difference has notably changed how I write programs. Specifically, two namespacing choices inhibit my inclination to explicitly group small sections of related declarations. This broadly impacts both program structure and naming.

I’ve been working in Clojure for the better portion of a year now. I came to Clojure very excited to learn more about macros and symbolic programming. I learned some powerful concepts, but the takeaways were not what I expected. Overall, I found that macros are not a clear win.