Or to put it succinctly, focus on problems, the constraints and forces shaping those problems, and not solutions. Different technologies will come up with different solutions depending on the specifics of their culture and where they're being used, but the underlying problems come up a lot, and understanding where you've seen it before can make reaching for the correct solution a breeze.

For example, I was just talking with some Polymer folks last week about how to manage global data that needs to be passed between components. They're largely from a client-side, web, JS-heavy background, but after listening to them sketch out this approach that they'd found very useful, I was like "Oh, it's like a Monostate pattern for HTML." That's made it dramatically easier for them to explain their solution to other people, because C++/Java/C# devs know what Monostates are, and now they can just plug in the syntax of HTML and semantics of Polymer elements into everything they know about why the pattern might be useful, what its drawbacks are, how it fits in with other patterns, etc.

One of the sibling comments here mentions how you really ought to know things like testing frameworks, in-code documentation practices, logging, etc. before you can be considered to "know" a language. I'd agree, but I'd argue that knowing that these things exist and why they're important is about 80% of the battle to using them effectively. I can pick up a new language in a few weeks and while I won't be an expert on it, I'll at least know to check out the preferred unit testing framework, read up on the logging APIs, see what the language's philosophy on error handling is, etc. I don't have to start from scratch, because I've worked on projects where these things were important and used a variety of frameworks that all solve these problems in subtly different ways. No, I'm not going to be as quick or elegant as someone who's been working with the language for 10 years - but I'll also be miles ahead of a fresh grad out of college who is just encountering the concepts for the first time and needs to learn the language mechanisms and why they're important. And when technology changes so fast, that knowledge is a lot less likely to go stale than whatever framework is flavor of the month.

Like the old adage. Good programmers can write FORTRAN in any language.

One can read Perl code and say "this was written by a C programmer" for example, or "this was written by someone who knew Python better than Perl."

Switching between languages for me usually means at least one failed project which nobody ever sees.

Also I would not call myself superproductive, though I have been called that by others. A big reason some people think I am superproductive is they don't see where I spend most of my time.