What I’m thinking about
One line of code changed my perception of programming - In the first years of my career, I was fascinated by building products. I could masterfully chain together libraries and integrate third-party services. But I knew little about separation of concerns, coupling, and software design. This changed in a single afternoon.
An article worth reading
Primer on functional architecture - Most functional programming articles are focused on low-level practices and the details in a codebase - pure functions, immutability, currying, and so on. A question that remains unanswered is how we apply FP when structuring an application or designing an entire system.
A video worth watching
Functional core, imperative shell - This is a hands-on example of how we can apply functional programming in the context of an application. The business logic becomes this encapsulated entity, written in a functional way. Free of side effects and state it can be tested easily. It is then wrapped in an imperative shell that becomes its interface to the world and deals with I/O.
An idea worth exploring
The entity service anti-pattern - The textbook definition of a microservice is an independently deployed application that represents a part of the business domain. We may be taking this too much to heart, though. Many microservices become hosts for all kinds of operations related to a specific domain entity. This article explores an alternative view - that each microservice should represent a part of the business workflow, not an entity per se.
A practice worth doing
How to edit - Writing and programming have more in common than most people realize. As engineers, we can learn a lot from how good writers approach their craft and how they edit their work. Write the program in the most imperative, naive way possible, then step away for a bit. Good software design comes with editing and you need a fresh pair of eyes for that.
A quote worth pondering
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." — Brian W. Kernighan