The languages that I've used with static typing are Java and Objective-C so perhaps those languages have negatively impacted my perception of type systems. I can do more research on other languages to see what they have to offer.

I used to run into type errors when I first started programming but I've learned how to eliminate them by changing my programming style. I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is.

I take a lot of pride in my work and try my best to build maintainable systems that can be extended easily or run forever without changes. I typically write around 250K-350K lines of code per year in mission critical and highly regulated industries. If you want to learn how to write systems that have zero defects research companies that are known for quality design and apply their principles to your own work. I would suggest Netflix, and Toyota as the two companies that I would emulate.

> I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is.

And you find it unbelievable that someone would prefer that the compiler simply enforce these conventions?

I don't find it unbelievable, I just personally don't get the appeal because you have to do that work when you name things anyway. e.g. I would never expect a variable named "first_name" to be anything other than a string. It's also fairly easy to handle most type conversions so I would rather be permissive in what I accept (to a reasonable point) than be rigid.

Well what are the properties of config_options or app_user or objects like these? Is it even documented, or am I forced to scan the entire method trying to figure out?

Typically I would initialize an AppUser object and print out its default representation. You can quickly find info on an object by doing something like:

    AppUser.new 
      => prints all properties of the object with nil values 

    AppUser.instance_methods - ActiveRecord::Base.instance_methods 
    => prints all unique instance methods on that class

values

config_options is extremely generic but I would expect that it is a Hash of key/value pairs. Given the fact that it has options in the name you are likely going to have to look it up regardless as you have multiple choices when using it. I'd expect some documentation if it is truly configurable, or you can transparently look at the method signature if it uses keyword args. (say for a library that handles formatting currency)

Quickly reading other people's code is a definite skill. While it can be a pain to do, it is worthwhile since the code is the only real source of truth.

Yeah, of course there are ways of doing it. But if you define types you can in a second be looking at all the possible values. The tools help you be more productive and make fewer mistakes.