Brilliant! Loved it!!! 🎉 🎉 🙏 🙏

@U6VPZS1EK Thanks!

Nice to get something a little more concrete. It's still a relatively small example, but it captures the idea of separating what Eric Normand calls "calculations" from "actions". I liked the nuance introduced by the byte buffer example: there's different ways to separate. I https://jbullers.github.io/posts/2023-10-05-testing-and-testability about the testing angle recently (in Java, but I'm sure ideas are transferable). One of the points I try to make is that designing for testing shouldn't take your design somewhere you don't want it to go. The byte buffer is a nice example of that: the design needs performance, but it still provides a seam for testing. It's kind of like buying the cake mix box, but in the box are a couple pouches you need to combine. It's still cake mix, but you can inspect things if you need to. Looking forward to some bigger examples, maybe something around namespaces and how you might insulate your domain from your database while providing a good way to test things (e.g. how do you swap out a db server for something in memory?), especially if you aren't doing the "obvious" thing of protocols and records to make the seams. Doing that feels familiar to me from an OOP background, but I lose the method type contracts, so it's hard to know (without reading implementations) "ah, this data source argument must implement this protocol because in the function body, foo and bar are called". Are there other organizational patterns that give the same benefits and perhaps aid in understanding larger systems?

This was good! Not to go too deep into the weeds, but when you extract parts of a function, do you have your own Clojure-informed refactoring technique for Extract Method? And this may be a case-by-case basis and might even be it's own podcast, but given that this would be reusable code, would you tend to extract to a separate file?