Blog

Side-effects (aka I/O) can make your code hard to test, understand, and change. In web dev, you have 3 options:

1. Use languages that don’t have side-effects; Elm for UI, and Roc for API/CLI.
2. Abstract away the side-effects using Effect-TS.
3. Use Functional Core, Imperative Shell in TypeScript, which requires you to manually separate pure code from side-effects.

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.