[dasil003]

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.

[nostrademons]

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.