5 ms·

For most programmers its not the new language, its the custom libraries, obscure frameworks, legacy code, or tooling that is going to be an issue for them.

by robotic 13y ago

humanrebar 13y ago
True, but I've seen lots of crummy in-house "custom libraries, obscure frameworks, legacy code, [and] tooling" that would have been better if they had been written by veterans of the target language. Or better yet, the veteran would know how to apply an off-the-shelf technology to solve the same problem.
Pxtl 13y ago
Exactly. I can get a guy up to speed with C# in a matter of hours. The problem comes up when we've got to deal with issues in IIS, Entity Framework, ASP.Net MVC, etc. etc. Most commodity programming languages are simple. Either they feel kinda like Javascript, or they feel kinda like Java. Obviously there are a few shops out there doing elaborate stuff with Clojure and they have a higher bar, but probably 95% of the work out there is being done with "typical statically-typed VM-based language" or "typical dynamically-typed language".
- matthewmacleod 13y ago
  I don't really agree. While you can certainly explain the basic syntax of a language in a few hours (assuming a developer who is at least familiar with a diversity of other languages,) it take a lot of time for most developers to become skilled at writing efficient, idiomatic code on a new platform.
a8da6b0c91d 13y ago
I never really got the glib claim you can just hire people and get them up to speed in a month. In my experience it takes almost a year to get truly familiar with how everything is done in a platform. It's not that one can't be productive quickly, it's that one will do many stupid and time consuming things.
- logfromblammo 13y ago
  It doesn't seem quite so ridiculous when you realize that the endemic attitude is that the company should be able to hire someone that can "hit the ground running" and be productive from the hire date. From that perspective, allowing for a whole month of training seems almost extravagant. That is why people say it. It is to counteract the sheer idiocy of expecting instant productivity.
egeozcan 13y ago
Most of which can be summarized as "magic". The less "magic" you have, easier it is to fill new positions.
- JoeAltmaier 13y ago
  You have some IP; that's your magic. Its always there. The less IP, the easier to compete with you. Catch-22.
  - nbouscal 13y ago
    IP doesn't have to be magical, not in the sense the parent was referring to. Well-documented modular libraries that perform a specific task well are thoroughly un-magical, and also incredibly valuable IP.
    - JoeAltmaier 13y ago
      Custom libraries are magic in the sense the OP used that term. So I agree there is no point in calling it all magic; its got to be there, so deal with it.

For most programmers its not the new language, its the custom libraries, obscure frameworks, legacy code, or tooling that is going to be an issue for them.

by robotic 13y ago

For most programmers its not the new language, its the custom libraries, obscure frameworks, legacy code, or tooling that is going to be an issue for them.

humanrebar 13y ago

True, but I've seen lots of crummy in-house "custom libraries, obscure frameworks, legacy code, [and] tooling" that would have been better if they had been written by veterans of the target language. Or better yet, the veteran would know how to apply an off-the-shelf technology to solve the same problem.

Pxtl 13y ago

Exactly. I can get a guy up to speed with C# in a matter of hours. The problem comes up when we've got to deal with issues in IIS, Entity Framework, ASP.Net MVC, etc. etc. Most commodity programming languages are simple. Either they feel kinda like Javascript, or they feel kinda like Java. Obviously there are a few shops out there doing elaborate stuff with Clojure and they have a higher bar, but probably 95% of the work out there is being done with "typical statically-typed VM-based language" or "typical dynamically-typed language".

matthewmacleod 13y ago
I don't really agree. While you can certainly explain the basic syntax of a language in a few hours (assuming a developer who is at least familiar with a diversity of other languages,) it take a lot of time for most developers to become skilled at writing efficient, idiomatic code on a new platform.

a8da6b0c91d 13y ago

I never really got the glib claim you can just hire people and get them up to speed in a month. In my experience it takes almost a year to get truly familiar with how everything is done in a platform. It's not that one can't be productive quickly, it's that one will do many stupid and time consuming things.

logfromblammo 13y ago
It doesn't seem quite so ridiculous when you realize that the endemic attitude is that the company should be able to hire someone that can "hit the ground running" and be productive from the hire date. From that perspective, allowing for a whole month of training seems almost extravagant. That is why people say it. It is to counteract the sheer idiocy of expecting instant productivity.

egeozcan 13y ago

Most of which can be summarized as "magic". The less "magic" you have, easier it is to fill new positions.

JoeAltmaier 13y ago
You have some IP; that's your magic. Its always there. The less IP, the easier to compete with you. Catch-22.
- nbouscal 13y ago
  IP doesn't have to be magical, not in the sense the parent was referring to. Well-documented modular libraries that perform a specific task well are thoroughly un-magical, and also incredibly valuable IP.
  - JoeAltmaier 13y ago
    Custom libraries are magic in the sense the OP used that term. So I agree there is no point in calling it all magic; its got to be there, so deal with it.