3 ms·

> It’s oddly common to see people talk about how a programmer can pick up something new in the matter of a few days or months. I see this and it bothers me as

> It’s oddly common to see people talk about how a programmer can pick up something new in the matter of a few days or months. I see this and it bothers me as well. Sure, picking up new language syntax isn't that big of a deal, but to become reasonably proficient at solving problems with a programming language takes a huge investment of time and energy.

StavrosK 13y ago
It's the difference between learning enough to be conversational in a spoken language and learning enough to write a novel in it. Maybe the people who think they can do it in a few months have never written a novel in any language?
- falcolas 13y ago
  Most developers don't need to ever write novels, and most development tasks do not involve writing novels, for what that's worth.
- Buttons840 13y ago
  The people who think they can learn a new language in a few month, indeed, might never write a novel, but they are out there writing crappy code I'll probably have to maintain on day. They're also getting paid well I might add.
schmichael 13y ago
I would say learning the syntax and features of languages like Scala and Haskell is quite hard (at least perhaps for people of C++/Java/C#/Python backgrounds). Languages like Go and Python take very little time to learn the language features even though mastering any language is quite an undertaking.
- paulrademacher 13y ago
  What's really hard is not mastering the language, but software development. That's the reason top, super-productive coders can jump between langs.
  - bsaul 13y ago
    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.
  - dasil003 13y ago
    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 13y ago
      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.
- SEJeff 13y ago
  Python and Go languages are super easy to learn. It might take you years to learn the standard library of either in-depth however.
- CmonDev 13y ago
  C# is quite a functional language now (monads, lambdas, anonymous types etc.). C# is probably the next closest thing to Scala.
jghn 13y ago
I have never bought the party line that learning languages for a new job is difficult, particularly from hiring managers. Multiple times in my career I've taken a job which required a new language, scala most recently. These all involved new frameworks, library stacks, etc. In each of those cases I was reasonably productive after a couple of weeks and productive enough after a month or two. It's not like I was the world's expert in those languages and at that point and I'd probably flub the sort of interview questions focused on the nitty gritty (heck, I've never been good at those regardless) but I knew what I wanted to do, had a good idea of how to do it and a minute or so with google would fill in the rest.
- memracom 13y ago
  Let's face it, if you practice TDD (i.e. write tests first) and you have access to a browser and Internet connection, why would you need to memorize libraries? Sure you might make a few more mistakes than someone steeped in the platform, but I just don't see it making a difference when you consider the amount of time you need to get up to speed on a new company's quirks and needs.

StavrosK 13y ago

It's the difference between learning enough to be conversational in a spoken language and learning enough to write a novel in it. Maybe the people who think they can do it in a few months have never written a novel in any language?

falcolas 13y ago
Most developers don't need to ever write novels, and most development tasks do not involve writing novels, for what that's worth.
Buttons840 13y ago
The people who think they can learn a new language in a few month, indeed, might never write a novel, but they are out there writing crappy code I'll probably have to maintain on day. They're also getting paid well I might add.

schmichael 13y ago

I would say learning the syntax and features of languages like Scala and Haskell is quite hard (at least perhaps for people of C++/Java/C#/Python backgrounds). Languages like Go and Python take very little time to learn the language features even though mastering any language is quite an undertaking.

paulrademacher 13y ago
What's really hard is not mastering the language, but software development. That's the reason top, super-productive coders can jump between langs.
- bsaul 13y ago
  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.
- dasil003 13y ago
  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 13y ago
    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.
SEJeff 13y ago
Python and Go languages are super easy to learn. It might take you years to learn the standard library of either in-depth however.
CmonDev 13y ago
C# is quite a functional language now (monads, lambdas, anonymous types etc.). C# is probably the next closest thing to Scala.

jghn 13y ago

I have never bought the party line that learning languages for a new job is difficult, particularly from hiring managers. Multiple times in my career I've taken a job which required a new language, scala most recently. These all involved new frameworks, library stacks, etc. In each of those cases I was reasonably productive after a couple of weeks and productive enough after a month or two. It's not like I was the world's expert in those languages and at that point and I'd probably flub the sort of interview questions focused on the nitty gritty (heck, I've never been good at those regardless) but I knew what I wanted to do, had a good idea of how to do it and a minute or so with google would fill in the rest.

memracom 13y ago
Let's face it, if you practice TDD (i.e. write tests first) and you have access to a browser and Internet connection, why would you need to memorize libraries? Sure you might make a few more mistakes than someone steeped in the platform, but I just don't see it making a difference when you consider the amount of time you need to get up to speed on a new company's quirks and needs.