That's the first thing you do: read/learn the data structures you're working with. As Linus said once:

> Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it.

Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.

That's great unless you are working with a codebase that spans decades and tens of millions of lines of code. At that point if for every assignment you are tracing through your data types manually - you are out of a job.

Also, if I am using an API another team is providing - I don't want to have to go and trace through their code.

And that's assuming you even have access to said source code. In many cases, you just receive a semi-documented JSON object and a prayer.

Anecdotal story: We recently went through an effort to introduce strict-type checking for our typescript backend. As part of that effort, we introduced concrete types for every API accessible across a service boundary, which caught 6 mismatches between the documentation and the implementation (e.g. return Promise<bool> vs Promise<Instance>) and several hundred issues with missing null or type checks that would result in an "InternalServerError" instead of a meaningful error message.

We started rolling the strict version out this week, and we can already see a meaningful improvement in the sentry logs.