> Type annotations let you get the shape of the data structure out of your head and into code.
This is by far the best argument for static typing I've ever heard. I'm not a big fan of static typing (mostly due to Java). I like Scala, but I think its type system is way over the top.
For the most part, I care about rapid development, and you'll always need unit tests anyway, so they can also test your types for you. And Scala type matching in its builtin switch statements can always get my type back when I get handed an Object. With tools like that, I don't really need absolute type safety.
But getting the shape of your data structures out of your head, that's definitely an advantage.
Type annotations let you get the shape of the data structure out of your head and into code. The compiler can then ensure that you're using the data structure properly.
Whereas if you're using a dynamic language without type annotations, you need to keep the shape of the data in mind; after that array index, hash lookup, function call, you need to know what kind of thing it is you've got in hand, and what you can do with it. Sure, you write tests to exercise the code and flush out the mistakes, but that isn't as tight an iteration cycle as a compiler - if living in an IDE, the cycle may be as low as a few milliseconds.
And this is the point of the "not a great programmer" comment. Making progress even though you don't have the entire map of the whole program's data structures in your mind all at once.
Having said that, I think this ability to deal with a lot of complexity in working memory can be detrimental to good code, even in typed languages. I've worked with some talented programmers that had an enormous capacity for complexity, but that very complexity made them less inclined to abstract their code. In fact, because they had less need for abstraction, their abstraction skills overall were poorer.