I'm bewildered because every senior dev I've ever spoken to has been somewhat unanimous about the use of types and tests. Reading this I'm wondering if there's

I'm bewildered because every senior dev I've ever spoken to has been somewhat unanimous about the use of types and tests. Reading this I'm wondering if there's a special context where this proposed approach is more suitable? Possibly a single dev, tiny sealed program? For every other system, be it with more than 1 developer or that will grow to more than 10s of functions, types and tests eliminate being anchored to the code you've written in the past. The #1 be benefit to them is you can forget about what you've written. It's unlikely you'll remember in 6 months time that one function where you can't pass in negatives or Nil. Do you want to have to read the internals of every function you're calling? Isn't that a violation of some open/closed principal? There is nothing sweeter than defining your intent in code contracts and confirming those contracts work before letting you or anyone else use them. If you don't want negatives being passed to your function, maybe unsigned integers aren't a good idea. Maybe make it explicit that you're sending in an 'age' value by defining it as a value object with its own validation. Make it blow up in the hands of the consumer as fast as possible. If you're waiting until runtime to tell you these things then you're not going to enjoy development. And your peers will hate maintaining your junk code.