I would consider Ian Bicking to be a "top, super-productive coder" and he is saying exactly the opposite. In fact not to put words in his mouth, but I think he would agree with my opinion that you can not master something as broad and unqualified as "software development". You can only achieve the level of mastery he is talking about within a domain your are focused on for many years. Software in the gestalt is just too broad, it is arbitrary, any logical construct you can imagine can be built, but without an application deeply considered your efforts and crafting the perfect architecture with just the right tradeoffs will flounder. It's one thing to be a learned hacker who understands many paradigms, patterns and language features and can whip up a solution to anything in short order; it's a completely different thing to build an architecture that people consider brilliant and becomes a pillar of open-source.
I may be putting words in the grandparent poster's mouth, but I didn't read his post as saying you can be an expert at all "software development", but rather that there are certain skills that cut across languages, and then what you see in a specific language is one specific manifestation of that pattern. Learning those skills is both harder and more generally useful than learning any one specific language.
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.
Super productive coders can't master languages within a few weeks.
They probably learn some of the syntaxes but they don't learn the idioms and proper ways of using the languages.
I've never met a developer who can pick up a book and be a master in relatively quick. They can hack something up but by no means the code is acceptable.
The only reason we believe someone can jump between languages quickly is because we _NEVER_ see their work and we _NEVER_ put them under microscope. We just believe the hype.
By acceptable I refer to the following criteria:
- Proper test automation
- Proper documentation (in-language doc)
- Proper idiom (that means logging properly, proper design pattern suitable for that language, using proper libraries/standard-lib correctly)
Anything less than that is a sign of either the language ecosystem is not mature enough or the developer has yet reached the mastery level (or simply not enough data to measure the level accurately).
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.
Of your four points, the first two strike me as generic development skills (knowing what and when to test, knowing what and when to document), and the forth is just reading the docs and following their instructions once. Proper idiomatic language use is probably the only thing you mentioned that is language specific.
Writing "proper" javadoc takes time. It has tons of keywords and annotation to make it look consistent like any other "professional and good looking" javadoc out there.
For example: if one is deprecating a method, there are a bunch of proper JavaDoc ways to do this (starting with the @deprecated annotation, not to be confused with another @Deprecated annotation, don't forget to state since which version this method is deprecated, etc etc).
It requires a high level of discipline and knowledge of the javadoc idioms.
Yes and no. Writing test cases can be rather different by language.
Also documentation frameworks may seem identical if you only program in C, C++, and Java. However when you start doing a lot in SQL, Perl, or Python, they start looking very different (and in fact these languages, assuming an SQL that supports COMMENT ON syntax) are more similar than any of them are to C or Java in this regard).
Move from there to TeX or LaTeX and you are in for another big shock.
In short, there are idioms for both test cases and documentation and those are remarkably language-specific.
I would generaly agree on that, but considering the fact that the OP has actualky created pip and virtualenv, i would say that for going that deep in a language and its ecosystem one really need some time.
