Typing is never the limiting factor in my work. Like, if I had to type even double to accomplish the same program, I don't think that would actually slow me down. Given that, the major time difference between using static vs dynamic typing is the investment needed to go from 'throwing things at a wall and seeing what sticks' to understanding what you need to do and doing it.
And as for how this relates to static v dynamic typing, when I'm roughing out an implementation I much prefer to leave out types.
The whole point of dynamic languages is that your problem space is in fact dynamic. In many domains your data simply defies any ontology you try and force it into. Static typing systems themselves are somewhat acknowleging this problem internally with the differences between nominal and structural based typing system.
Dynamic langauges are about changing your view on data where instead of shoving all your data into and out of boxes that don't fit, you just see entities as arbitrary collections of attributes and thus typing them makes little sense.
The gist is basically that a dynamic type system doesn't afford you any more power or "dynamicism" than a statically typed language.
At any point in time, when writing code, you always know something about your data. Even if it was quite literally totally unstructured JSON data with no rhyme or reason to its structure other than it being any valid JSON, then at least you know that much, and you can reify this in the type system: `data JSONVal = Map String JSONVal | [JSONVal] | JSONString String | ..`
It is impossible to write code that works on "any kind of data" because your code, and what it does with the data, makes the same kinds of assumptions about the shape of the data as static typing does. The only difference is that a static type system will let the compiler help you find obvious bugs at compile-time, while dynamic typing will force you write tests up the wazoo and the end result will still be something that is less robust wrt. refactoring than a statically typed language. The statically typed language just gives you this all for free.
"In contrast, most static type systems do not allow such free-form manipulation of records because records are not maps at all but unique types distinct from all other types. These types are uniquely identified by their (fully-qualified) name, hence the term nominal typing. If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate."
That is exactly the space I want to work in. I want to treat entities as anonymous entities without having to name them them since at that point I approach a 1:1 mapping of names to things in my system. I want to use generic data operations to merge and slice my entities which are just collections of facts about a thing. Structural typing is a step towards this programming model but still requires that you shove your data into some ontology.
EDIT: Actually I take that back, that blog post is totally missing the point. She asserts that the type system just makes explicit the implicit requirements of your code. The problem is in HOW the type system does that. By focusing on the function itself, the author ignores the real problem further upstream. If there's some type, then I have to shove my dynamic data into your type in order to use the function. And if you're trying to use interfaces, there's still some concrete type that you've created to attach that interface too. Either way, you haven't managed to support dynamic data through your system.
Ironically this is what dynamic languages do. Everything is in boxes that could be anything.
It's worth bearing in mind that dynamic languages can be (and often are) built using statically typed languages. You can easily build dynamic collections using static typing.