>It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand

>It was a function that returned a function that accepted as a parameter another function and the extra syntax was really taxing to my brain to fully understand what the function was all about. When I removed the extra syntax it was way clearer for me to understand it. Interesting. Was that your first time reading TS? Higher order functions, specially when combined with optional arguments, in JavaScript are an easy source of bugs for me but never when using TS, since I can simply see what I'm being asked for and getting back. >Also I am a solo developer in my company I actually forgot that scenario. Yes, unless you have adapted to the type-driven development way of thinking you will hardly see many of the benefits of maintaining code that has types vs code that does not. When you're the one that wrote the code, you'll have an unfair advantage at understanding how the author meant the code to be used. When you don't have that luxury, types can be a great aid in most situations. Of course, it's a question of time and codebase size until you break your own preconditions when changing something, but you'll not notice how the type system can save you from that until it you actually learn how to take advantage of it. It's a catch-22, so if you're curious and want to see what's meant by "taking advantage of the type system", I can only suggest you that you give something like Elm a try. There you'll see many times in the first couple of weeks what types can do for you when changing code.