>This meant when we update a function signature we would often incorrectly update call sites, etc.

The same thing happened with our huge legacy PHP monolith, which was written before type hints were a thing. Developers were reluctant to refactor large chunks of code when the time came, because it was just too easy to introduce bugs - you couldn’t be confident about anything without manually digging through tons of code. So, when business requirements changed, they’d just bolt on some hacks to avoid touching the existing, tested code, and call it a day. It became a self-reinforcing loop: fear of refactoring → more hacks to avoid refactoring → more brittle code → even more fear of refactoring. Eventually, they added type hints and a linter to analyze them, but by that point you start to wonder - why are we even using a dynamic language and fighting its quirks?

This is something I watch out for: teams which fear their own code and operate defensively, typically with cargo-cult practices that accumulate even though they themselves aren’t well understood.

When I started, the culture was already engineered to prevent this reluctance. You would hear "the code is fragile, it's going to break. Noone will shout at you for that." This was great. But I would prefer to just not have to "run in eggshells" haha!

It can be solved with static analysis and type inference. Inference can be tricky though, as you have to backtrack and figure out what type of values functions return etc, so type hints/annotations make the job easier for the IDE/tooling developer, but they are not necessary!