4 ms·

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

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) - Proper SCM (that means build, dependency management, folder structure, code style, code analysis tool in-place, etc) 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).

falcolas 13y ago
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.
- einhverfr 13y ago
  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.
- edwinnathaniel 13y ago
  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. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html http://www.oracle.com/technetwork/java/javase/documentation/... Occasionally, one have to insert HTML too... I know C# support similar thing.
kamaal 13y ago
And also most people write the new language in their old language. Like the old adage. Good programmers can write FORTRAN in any language.
- edwinnathaniel 13y ago
  It happened to me once. My QBasic instructor guessed that I probably have taken a FORTRAN class (and I did...).
einhverfr 13y ago
I would agree. 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.

falcolas 13y ago

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.

einhverfr 13y ago
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.
edwinnathaniel 13y ago
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. http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html http://www.oracle.com/technetwork/java/javase/documentation/... Occasionally, one have to insert HTML too... I know C# support similar thing.

kamaal 13y ago

And also most people write the new language in their old language. Like the old adage. Good programmers can write FORTRAN in any language.

edwinnathaniel 13y ago
It happened to me once. My QBasic instructor guessed that I probably have taken a FORTRAN class (and I did...).

einhverfr 13y ago

I would agree. 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.