I think not getting hung up on a method to solving a problem is a great message to remember. You should be open to switch to a different method if it solves the

I think not getting hung up on a method to solving a problem is a great message to remember. You should be open to switch to a different method if it solves the problem better. Type safety is just one such method. The actual problem is making code easier to maintain for humans. Type safety is not always the best means to that end. Our brains perceive information in a complicated way. Sometimes too much information can overwhelm us and obfuscate something simple. Sometimes too much detail about each value can make us lose the overall flow of the program. My advice: (aside from reading other people's code) try to read what you wrote, and have others read what you wrote in code reviews. Do you and your colleagues understand it? Make it as brief and simple as possible without losing that understanding. Address any "how" questions by rewriting the code clearer, "what" questions by improving naming, and "why" questions by adding comments. These are your code's 3 primary objectives: explaining how, what, and why to your colleagues. I once wrote a post about it.[1] [1]: https://max.engineer/maintainable-code https://max.engineer/maintainable-code