4 ms·

I was struck by the same impression: why label or restrict yourself to a single language? And why label all other languages as short-lived, low quality fads? Be

by sspiff 13y ago

I was struck by the same impression: why label or restrict yourself to a single language? And why label all other languages as short-lived, low quality fads? Because that's what reading the two "tl;dr" sections at the top indicate. He's not doing himself any favours with that kind of statement. When people (recruiters or otherwise) ask me what I do, I'm a developer. Not a C programmer, not a Rubyist, or any subset of software development. I know how to program, I know how to solve problems, and I know how to learn new languages, libraries or frameworks. Sticking to your guns in an industry as ever-changing, for better or worse, as ours, is a bad idea. When I was a student, I was interested in trying out tons of new languages. I eventually ended up sticking to Ruby for most of my own projects. At university, we used Java almost exclusively. My two last jobs however, have been C and C++. I'm fond of C, but not a big fan of C++. If I had stuck to Ruby or Java, I doubt I'd have a job as interesting as the one I have now, as those to languages seem to be restricted to web development and things like low quality internal applications used by banks in my area. (Unrelated: odd, I'd never hear of this guy chromatic before today. I was listening to music by Chromatics, and five minutes before this thing hit front page, I decided to Google the bands name, and I ended up on his Wikipedia page.)

pekk 13y ago
Why refuse any specialization? Some things take years of experience in a language to get right. First, nobody should care that you can "hello world" in more languages. Second, you don't have any preferences about what tools you use?
- weavie 13y ago
  I think you should specialize in programming concepts first and specific languages second. Once you have a deep understanding of lambda calculus, mutable/immutable state, lazy/eager, classes/functions and all that, then first it is easier to approach any language and second you will have a much deeper knowledge of the languages (yes it should really be more than one) you do specialize in.
- existencebox 13y ago
  I think the statement was more like, "a developer uses the right tool for the job, a perl programmer will always use perl". (to the above poster, I hope I didn't misinterpret...) You need both, I think. Breath and depth. Excessive depth to the point of self identification as an "x" coder has often correlated with living in an "x" bubble in people I've met. I have some thoughts on this (which I'm badly composing now due to being in a rush), it's a really important conversation to have (what's the right balance between breath and depth) and frankly depends a LOT on the person/work. I would certainly fucking hope that, to give a strained example, my brain surgeon wasn't just a general practitioner with a hobby :P
- sspiff 13y ago
  Of course I have a preference, but in general you work in teams, and the quality of the code base and standard practices of the group are more defining in how fun or productive something is to work on than the choice of language. I know nobody cares if you can write "hello, world" in many languages, but I never stated that or anything like that, did I? Some things take time to learn (systems programming, memory management, ... are things you'll have to wrap your head around when coming from a higher level environment, for instance), but hardly any of them are language specific as far as I can tell. Feel free to point out examples to the contrary, although I feel like if it's hard to learn a general concept in a specific language, that sounds like a language design problem. In many cases being a good programmer in one language means you can learn another language and become a proficient or good programmer in it relatively easily. Some specialization is fine, however, if you really stick to a single language/framework/environment, I think you're staking an awful lot on something that could mostly go away in five years time. For example, I work in the embedded domain. Ten, fifteen years back, microcontrollers were pretty much king. You wrote software close to the metal, without an operating system, and allocated all memory statically. If you stuck to that kind of development, and refused to learn embedded Linux stuff or dynamic memory management, you'd be unable to find a job today (at least in my area, I can't speak for the entire world in this case.)
  - avar 13y ago
    You're right about a lot of this knowledge being transferable, but I think you might also be underestimating just how much useful specialist knowledge you can acquire specific to a particular toolchain, and how much of a step back starting over can be. I happen to have been doing Perl professionally for a while now and I'd say it would take me at least 2 years to get equally up to speed on another toolchain. Sure I can write programs productively in other languages, but with my language of choice I don't have to look up dozens of little things a day, avoid common and less common pitfalls all the time, and generally choose the easier path the first time around because I've been around the block a bunch of times. No matter what toolchain you use productivity at that level is hard to come by, and a lot of it is toolchain-specific. I can competently hack C but someone who's been doing it for 10 years will run laps around me. So while I'm certainly not married for life to the toolchain I'm using I also think that many people underestimate just how much effort it is to truly become completely intimately familiar with some tool, and how much you constantly gain in productivity for having done so.
- jakejake 13y ago
  I get a sense that some people change languages or frameworks frequently just due to boredom, inability to commit to any one thing or a desire to pad their resume with buzzwords. It's just like everything else - great programmers will tell you to learn multiple languages to expand your mind. Mediocre programmers will twist that around and use it as rational to flip-flop around without developing any deep knowledge.
jimejim 13y ago
Well, there's a popular term now for some HR people called T-shaped people. The idea is that you are a generalist that has some deep knowledge in at least one specific area. It's not a bad idea to pick one specialization if you are interested in something. The person in this article needs to adjust the language to emphasize that he knows about the rest of the world outside of Perl, but just happens to have a strong background there.

by sspiff 13y ago

pekk 13y ago

Why refuse any specialization? Some things take years of experience in a language to get right. First, nobody should care that you can "hello world" in more languages. Second, you don't have any preferences about what tools you use?

weavie 13y ago
I think you should specialize in programming concepts first and specific languages second. Once you have a deep understanding of lambda calculus, mutable/immutable state, lazy/eager, classes/functions and all that, then first it is easier to approach any language and second you will have a much deeper knowledge of the languages (yes it should really be more than one) you do specialize in.
existencebox 13y ago
I think the statement was more like, "a developer uses the right tool for the job, a perl programmer will always use perl". (to the above poster, I hope I didn't misinterpret...) You need both, I think. Breath and depth. Excessive depth to the point of self identification as an "x" coder has often correlated with living in an "x" bubble in people I've met. I have some thoughts on this (which I'm badly composing now due to being in a rush), it's a really important conversation to have (what's the right balance between breath and depth) and frankly depends a LOT on the person/work. I would certainly fucking hope that, to give a strained example, my brain surgeon wasn't just a general practitioner with a hobby :P
sspiff 13y ago
Of course I have a preference, but in general you work in teams, and the quality of the code base and standard practices of the group are more defining in how fun or productive something is to work on than the choice of language. I know nobody cares if you can write "hello, world" in many languages, but I never stated that or anything like that, did I? Some things take time to learn (systems programming, memory management, ... are things you'll have to wrap your head around when coming from a higher level environment, for instance), but hardly any of them are language specific as far as I can tell. Feel free to point out examples to the contrary, although I feel like if it's hard to learn a general concept in a specific language, that sounds like a language design problem. In many cases being a good programmer in one language means you can learn another language and become a proficient or good programmer in it relatively easily. Some specialization is fine, however, if you really stick to a single language/framework/environment, I think you're staking an awful lot on something that could mostly go away in five years time. For example, I work in the embedded domain. Ten, fifteen years back, microcontrollers were pretty much king. You wrote software close to the metal, without an operating system, and allocated all memory statically. If you stuck to that kind of development, and refused to learn embedded Linux stuff or dynamic memory management, you'd be unable to find a job today (at least in my area, I can't speak for the entire world in this case.)
- avar 13y ago
  You're right about a lot of this knowledge being transferable, but I think you might also be underestimating just how much useful specialist knowledge you can acquire specific to a particular toolchain, and how much of a step back starting over can be. I happen to have been doing Perl professionally for a while now and I'd say it would take me at least 2 years to get equally up to speed on another toolchain. Sure I can write programs productively in other languages, but with my language of choice I don't have to look up dozens of little things a day, avoid common and less common pitfalls all the time, and generally choose the easier path the first time around because I've been around the block a bunch of times. No matter what toolchain you use productivity at that level is hard to come by, and a lot of it is toolchain-specific. I can competently hack C but someone who's been doing it for 10 years will run laps around me. So while I'm certainly not married for life to the toolchain I'm using I also think that many people underestimate just how much effort it is to truly become completely intimately familiar with some tool, and how much you constantly gain in productivity for having done so.
jakejake 13y ago
I get a sense that some people change languages or frameworks frequently just due to boredom, inability to commit to any one thing or a desire to pad their resume with buzzwords. It's just like everything else - great programmers will tell you to learn multiple languages to expand your mind. Mediocre programmers will twist that around and use it as rational to flip-flop around without developing any deep knowledge.

jimejim 13y ago

Well, there's a popular term now for some HR people called T-shaped people. The idea is that you are a generalist that has some deep knowledge in at least one specific area. It's not a bad idea to pick one specialization if you are interested in something. The person in this article needs to adjust the language to emphasize that he knows about the rest of the world outside of Perl, but just happens to have a strong background there.