4 ms·

There was a recent comment by tptacek in another thread which I agree with: you really only need to know a couple of programming languages before you start hitt

by yen223 13y ago

There was a recent comment by tptacek in another thread which I agree with: you really only need to know a couple of programming languages before you start hitting diminishing returns in terms of what you can implement. We should focus instead on learning new concepts or new problem domains. I'm trying to revisit statistical modelling and pick up some machine learning basics over the next year.

gfodor 13y ago
and what about domains only tangentially related to computer science, like robotics, semiconductors, or digital music? or what about domains barely related to computer science, but where coding is an invaluable skill, like medicine/genetics, manufacturing, or aerospace? consider how many programming languages your average person knows (zero). now consider how many you know. is it objectively worth your time optimizing around that particular dimension within your skills, or are you perhaps suffering from a latent bias you have from the fact that you are a relative expert in programming? would you rather have a carpenter who knows how to use a dozen hammers, or a wide variety of tools? is haskell a new tool, or is it just another hammer for you? with coursera you have no excuse to avoid stepping outside your comfort zone!
- velis_vel 13y ago
  > would you rather have a carpenter who knows how to use a dozen hammers, or a wide variety of tools? There's a danger in what you're suggesting, in overgeneralizing and never learning too much about one topic. Would you rather have a carpenter who's an okay carpenter, an okay musician, an okay actor, and an okay racecar driver, or a carpenter who's really good at carpenting?
  - gfodor 13y ago
    well, my point is a person needs to determine on their own if learning something like haskell really makes them a better carpenter, or if they are just going leveling up their "number of programming languages" XP because that's the main XP they are familiar with. If I had to pick a point of leverage with which to increase programming skill in minimal time, "learn a new programming language" would be far down the list if two or three for various contexts were already well mastered. "Learn Haskell", almost universally, would be near the bottom.
    - peterfoldi 13y ago
      I agree with you that it is everybody's own decision :) Although from a slightly philosophical point of view: how can one determine what levels are beyond their own knowledge, let alone what amount of effort it would take for them to get there and if it would worth it to do so. An experienced developer can tell a beginner what they could/should learn next to step up, but how do you determine the same for yourself? On the other hand I strongly dislike the "in minimal time" condition. After let's say 10 years or more in programming (that's me in this case) and you say that the next step one could achieve is something that comes faster than learning a new programming paradigm? My gut feeling is that it will take me about 6 months with a strong programming background. I am not talking about learning Haskell (What could it be: a week or so?) but about understanding FP, knowing (and feeling) the fp design patterns. Depending on the investment in 6 months one probably can achieve that the application of those patterns come as second nature. That's my goal. Two questions: 1) What would give greater and longer-term benefits than that? Learning Reactive Extensions? Yet another ORM framework? Node.js? Those are only tools. One can learn them in some days when a project requires it. 2) What is the rush for? Do you remember the time you learnt OO programming? I would say to learn it properly, in the beginning of your career as most of us do it, required much more effort than to learn Haskell and FP when you are already an experienced programmer. Wasn't it worth to spend all that time to learn OO principles, design-patterns, tools, languages? And if you were stuck in the OO world throughout your career, then I am pretty sure that learning FP principles, patterns and language(s) have about the same effect on your future than OO had on your present expertise.
      - gfodor 13y ago
        when I said "minimal time" I meant "minimal time per unit of skill increase." sorry this wasn't clear. the whole point is if your goal is to improve your skills as a programmer you should be optimizing your time to learn things that provide the largest skill increase per unit time. as far as your first point goes, I agree that some type of random walk part is important to breaking out of local maxima. you can look to social cues for what might be a good thing to start learning about that is outside of your comfort zone. generally speaking since software is eating the world a good litmus test for me is if the domain seems to be amenable to automation and is also not as far along the curve as more "easy" domains to dive into like the latest newfangled way to build a web based CRUD app.

by yen223 13y ago

gfodor 13y ago

and what about domains only tangentially related to computer science, like robotics, semiconductors, or digital music? or what about domains barely related to computer science, but where coding is an invaluable skill, like medicine/genetics, manufacturing, or aerospace? consider how many programming languages your average person knows (zero). now consider how many you know. is it objectively worth your time optimizing around that particular dimension within your skills, or are you perhaps suffering from a latent bias you have from the fact that you are a relative expert in programming? would you rather have a carpenter who knows how to use a dozen hammers, or a wide variety of tools? is haskell a new tool, or is it just another hammer for you? with coursera you have no excuse to avoid stepping outside your comfort zone!

velis_vel 13y ago
> would you rather have a carpenter who knows how to use a dozen hammers, or a wide variety of tools? There's a danger in what you're suggesting, in overgeneralizing and never learning too much about one topic. Would you rather have a carpenter who's an okay carpenter, an okay musician, an okay actor, and an okay racecar driver, or a carpenter who's really good at carpenting?
- gfodor 13y ago
  well, my point is a person needs to determine on their own if learning something like haskell really makes them a better carpenter, or if they are just going leveling up their "number of programming languages" XP because that's the main XP they are familiar with. If I had to pick a point of leverage with which to increase programming skill in minimal time, "learn a new programming language" would be far down the list if two or three for various contexts were already well mastered. "Learn Haskell", almost universally, would be near the bottom.
  - peterfoldi 13y ago
    I agree with you that it is everybody's own decision :) Although from a slightly philosophical point of view: how can one determine what levels are beyond their own knowledge, let alone what amount of effort it would take for them to get there and if it would worth it to do so. An experienced developer can tell a beginner what they could/should learn next to step up, but how do you determine the same for yourself? On the other hand I strongly dislike the "in minimal time" condition. After let's say 10 years or more in programming (that's me in this case) and you say that the next step one could achieve is something that comes faster than learning a new programming paradigm? My gut feeling is that it will take me about 6 months with a strong programming background. I am not talking about learning Haskell (What could it be: a week or so?) but about understanding FP, knowing (and feeling) the fp design patterns. Depending on the investment in 6 months one probably can achieve that the application of those patterns come as second nature. That's my goal. Two questions: 1) What would give greater and longer-term benefits than that? Learning Reactive Extensions? Yet another ORM framework? Node.js? Those are only tools. One can learn them in some days when a project requires it. 2) What is the rush for? Do you remember the time you learnt OO programming? I would say to learn it properly, in the beginning of your career as most of us do it, required much more effort than to learn Haskell and FP when you are already an experienced programmer. Wasn't it worth to spend all that time to learn OO principles, design-patterns, tools, languages? And if you were stuck in the OO world throughout your career, then I am pretty sure that learning FP principles, patterns and language(s) have about the same effect on your future than OO had on your present expertise.
    - gfodor 13y ago
      when I said "minimal time" I meant "minimal time per unit of skill increase." sorry this wasn't clear. the whole point is if your goal is to improve your skills as a programmer you should be optimizing your time to learn things that provide the largest skill increase per unit time. as far as your first point goes, I agree that some type of random walk part is important to breaking out of local maxima. you can look to social cues for what might be a good thing to start learning about that is outside of your comfort zone. generally speaking since software is eating the world a good litmus test for me is if the domain seems to be amenable to automation and is also not as far along the curve as more "easy" domains to dive into like the latest newfangled way to build a web based CRUD app.