Functional Programmers learn pretty early that Maybe/Optional should be avoided if possible. While many languages have lifting abilities to make them easier to work with, they end up littering your code with multiple places you have to handle the case where the data simply isn’t there. This is one of the reasons you see “Parse, Don’t Validate” pushed so heavily; you no longer have to write so many unhappy paths in the code, just 1 in the beginning.
Dave Farley calls it the Mockery. Jason Gorman has a video calling it Mock Abuse and Mock Hell. Both are true. I’m dealing with it at work and trying to gather various resources to help teach why this is a bad thing. I think Jason’s video has the best summary I’ve ever seen on it because “too many mocks” really are a symptom of a bad design.
Finally got around to reading Domain Modeling Made Functional, Tackle Software Complexity with Domain-Driven Design and F#, by Scott Wlaschin. Book basically covers:
Quick commentary on the ThoughtWorks 2025 Tech Radar; their yearly report on things to try, adopt, and avoid (they call it “hold”, meaning proceed with caution whereas I’m like “yeah, no, avoid the noid”). I only cover the ones I find interesting, so if you want to read the whole thing, PDF is downloadable here: https://www.thoughtworks.com/en-us/radar
