5 ms·

If you really care which programming languages I already know or which applications I have used before, I can only assume that you're overlooking my ability to

by azanar 16y ago

If you really care which programming languages I already know or which applications I have used before, I can only assume that you're overlooking my ability to quickly pick up new technologies and adjust to new ways of thinking. This is going to ruin your world view, so brace yourself So, this is ridiculously tongue-in-cheek, and the reply is over-the-top to the degree that I can imagine with no effort the same being uttered from underneath a drill sergeant's hat against some fresh recruit who copped a serious attitude. It's not an unfair response to brash cockiness, but it has set me thinking. Whether a language, or a framework, or a library, or any other handy tool of the software trade, there seems to be two camps that drown everyone else out in the din. There's the camp that declares that learning new things is a matter of extrapolating from the understanding one has already developed to fit with whatever assumptions this instantiation of thing X makes. For instance, you understand what Object Oriented programming is, and how it works. You are presented with a language you have never used before, but know it has support for OO. This puts you from a level of having to understand OO to a level of understanding this language's semantics for OO. Then there's the camp that declares that learning new things always starts from a position of absolute ignorance. Prior knowledge and understanding of concepts that would seem to apply to this new thing you are learning don't apply, almost as an axiom. As with my example of OO above, it doesn't matter that you know what OO is, and what it means to the structure of your program. If you don't know OO in the language of discussion, you get no points toward credit of understanding OO. If I may be blunt, both these stances seem like bullshit. You don't magically know the syntax of how to do OO in a new language simply because you know OO from a theoretical level; it's something you have to look up. But different languages' implementation of OO aren't so disparate that the only thing they share is the name. There is a basis there you can rely on, but it doesn't get you 100% of the way there. I guess the question I don't think people answer enough, which I would like to inject into the conversation is "how far does it get you?" I realize that the answer will vary for different theoretical ideas, and different practical realizations of the same. The point of my question is to challenge the presumption that understanding of related concepts either gets you to the finish by default, or leaves you gasping at the starting along with the people who didn't have that understanding. I think this gets left behind when we start having all of these political battles based on generational identity, and I'd like to see what people think when smacking other generations around isn't the primary goal of a thread.

timwiseman 16y ago
The real question seems to be: What is this hypothetical corporation looking for? If my company wants someone that can come in and start coding from day 1 then yes I want someone that already knows language x well, and can show me samples right now. I am deliberately overlooking your alleged ability to quickly pick up new technologies. If I am looking for someone to join the company for the long term and I am willing to train, then I might care more about your ability to learn quickly (but you better be ready to prove it...) and little about what you know now. In the real world, what I am looking for most of the time is in between. I want someone that I can assume will be with the company for a long time so they need to be able to learn and adapt as we change. But I also want someone that can be productive without a huge lead up time so they need to already know something really close to language x if not language x itself. In short, I normally want some of both and your alleged ability to quickly pick things up is not being overlooking, but it is only one part of the equation and I seriously want you to have something close to language X already.
- gawker 16y ago
  Agreed. Having experience with frameworks and languages will give you a headstart in being able to produce something quickly and might even provide some insight on the pros and cons of the said framework or language.
gaelian 16y ago
My two cents would be that it's almost always somewhere in between the two extremes you describe. Certainly having experience with OO in one language will be an advantage when it comes to picking up another OO language but yeah, you're not 100% there. I would posit that you're more than 50% there, though (with this particular example). Understanding the OO concept is more important than the syntax. You know what I find onerous when I think about learning a new language? It's not so much picking up the new syntax because a lot of the time I find that I can do that pretty quickly (at least if the paradigm between old and new language is not too disparate). It's picking up the ecosystem around the language: How do I deploy an application written in language X? How do I package code written in language X (e.g. Ruby gems, Python eggs or whatever)? Which unit testing frameworks do I learn? What IDEs or text editors are usually used with language X? Documentation conventions and related software (e.g. rdoc)? What community resources are valuable, trustworthy and stable? etc. When I first started learning Ruby (along with Rails, some years ago now) my web development experience mostly consisted of LAMP and ASP.Net. Deploying Rails apps seemed like such a massive hassle compared to PHP. Part of this was that Ruby as a web dev language was much newer than PHP and was still settling in, parts of it really were a hassle. But I came to realise that a big reason for the difference was that the two communities were conceptually coming at the issue of deployment from very different perspectives and a lot of the differences I was seeing were no accident, and not so difficult to grok when you understand the motivation behind them. A lot of non-programmers don't get that there is usually a fair amount of transferable knowledge when it comes to picking up a new language that utilises similar concepts to one you already know. But I can also understand that some (probably most) employers want their staff to "hit the ground running" and may be looking for people with a very specific skill set. Putting myself in the position of an employer and knowing what I do, I'd rather hire Person A that's obviously enthusiastic about learning new stuff, who's maybe contributed to something open source that can be reviewed, and who surely has some background knowledge that they can build on but who may not necessarily have language X listed on their resume, over Person B who does have language X on his resume but that's all they've really got. It would be good if more recruitment firms and HR departments started to realise that having the right acronym/keyword listed on your resume doesn't actually mean much on its own.

by azanar 16y ago

timwiseman 16y ago

The real question seems to be: What is this hypothetical corporation looking for? If my company wants someone that can come in and start coding from day 1 then yes I want someone that already knows language x well, and can show me samples right now. I am deliberately overlooking your alleged ability to quickly pick up new technologies. If I am looking for someone to join the company for the long term and I am willing to train, then I might care more about your ability to learn quickly (but you better be ready to prove it...) and little about what you know now. In the real world, what I am looking for most of the time is in between. I want someone that I can assume will be with the company for a long time so they need to be able to learn and adapt as we change. But I also want someone that can be productive without a huge lead up time so they need to already know something really close to language x if not language x itself. In short, I normally want some of both and your alleged ability to quickly pick things up is not being overlooking, but it is only one part of the equation and I seriously want you to have something close to language X already.

gawker 16y ago
Agreed. Having experience with frameworks and languages will give you a headstart in being able to produce something quickly and might even provide some insight on the pros and cons of the said framework or language.

gaelian 16y ago

My two cents would be that it's almost always somewhere in between the two extremes you describe. Certainly having experience with OO in one language will be an advantage when it comes to picking up another OO language but yeah, you're not 100% there. I would posit that you're more than 50% there, though (with this particular example). Understanding the OO concept is more important than the syntax. You know what I find onerous when I think about learning a new language? It's not so much picking up the new syntax because a lot of the time I find that I can do that pretty quickly (at least if the paradigm between old and new language is not too disparate). It's picking up the ecosystem around the language: How do I deploy an application written in language X? How do I package code written in language X (e.g. Ruby gems, Python eggs or whatever)? Which unit testing frameworks do I learn? What IDEs or text editors are usually used with language X? Documentation conventions and related software (e.g. rdoc)? What community resources are valuable, trustworthy and stable? etc. When I first started learning Ruby (along with Rails, some years ago now) my web development experience mostly consisted of LAMP and ASP.Net. Deploying Rails apps seemed like such a massive hassle compared to PHP. Part of this was that Ruby as a web dev language was much newer than PHP and was still settling in, parts of it really were a hassle. But I came to realise that a big reason for the difference was that the two communities were conceptually coming at the issue of deployment from very different perspectives and a lot of the differences I was seeing were no accident, and not so difficult to grok when you understand the motivation behind them. A lot of non-programmers don't get that there is usually a fair amount of transferable knowledge when it comes to picking up a new language that utilises similar concepts to one you already know. But I can also understand that some (probably most) employers want their staff to "hit the ground running" and may be looking for people with a very specific skill set. Putting myself in the position of an employer and knowing what I do, I'd rather hire Person A that's obviously enthusiastic about learning new stuff, who's maybe contributed to something open source that can be reviewed, and who surely has some background knowledge that they can build on but who may not necessarily have language X listed on their resume, over Person B who does have language X on his resume but that's all they've really got. It would be good if more recruitment firms and HR departments started to realise that having the right acronym/keyword listed on your resume doesn't actually mean much on its own.