4 ms·

Yes, but if the hospital ever needs to replace you they are SOL

by Zyst 8y ago

mruts 8y ago
Any developer worth their salt should be able to pick up a new language in a couple days. I'm not sure why some developers are so adverse to learning anything new.
- Bootvis 8y ago
  I don’t believe it, the internet is full of people that struggle to learn Haskell and even R. For many, it’s not that easy.
  - dragandj 8y ago
    But they only need to find one such developer; no need to employ the whole Internet.
- eternalban 8y ago
  How lucky are you to test your subjective theories [with] someone else's dime.
- JamesBarney 8y ago
  This just isn't true. There is a reason people look for devs with years of experience in a certain stack.
  - mruts 8y ago
    At work we use Scala in a very functional style and Akka. Not a single dev on our team (including me) knew Scala when they started. Everyone was productive with the codebase and programmed idiomatically within a matter of weeks.
    - JamesBarney 8y ago
      I imagine the team was familiar with writing Java, which makes moving to Scala the easiest possible language transition besides maybe a move from C# to VB.NET. Switching to a completely different ecosystem, such as to R, Racket, Haskell and C takes at least twice as long. And could be much longer if you're relying on large framework changes, for instance if you're switching from QT to GTK+ or WPF.
  - segmondy 8y ago
    Those developers ain't worth their salt.
    - JamesBarney 8y ago
      Are you arguing that developers graduate and hit maximal productivity in any stack in 3 weeks?
- AlexCoventry 8y ago
  The language itself, maybe... The ecosystem? Forget it.
- nemoniac 8y ago
  That's easily said but what's usually meant is that any programmer of a blub language (http://paulgraham.com/avg.html http://paulgraham.com/avg.html) is able to pick up another bulb language in a couple of days. Racket doesn't fall into the category of blub languages.
  - spacesuitman2 8y ago
    This. Racket simply allows you to address any problem domain in an even more powerful manner than other Lisp's: simply by creating a truly independent parser and interpreter that still has nice interop with the rest of racket. Not to mention, the metaprogramming facilities are the most advanced in the world.
- Zyst 8y ago
  I know Scheme, I am currently learning Elm. I like picking up fun languages. I also like working with them when possible. But I think the implication that a hospital board can confidently hire a developer that is "good", or one that will make good decisions in their behalf is wrong. For proof, see the OP of the thread. Their decision, I believe, directly harms the hospital's interests. He has essentially become irreplaceable, because they don't have the necessary skill set to confidently hire someone who will be able to replace them. Even if, in the best of cases, OP leaves for a better paying/what have you job hiring someone to fill their void will be hard. That's not what bothers me most, however. It's the attitude. It's us as developers going: "I picked the best tool for the job, and thus this solution will be intrinsically better for the business". Like we're doing them a favor. We're not doing them a favor, even if the tool is superior for the use case the difficulty of finding other people who could take over you introduces an amount of risk that almost no business that understand the full implications would allow. Worst case scenario, the tool(s) might need to get re-written from scratch. And the new versions could have bugs the old ones don't, or poorly handle all the one million edge cases that pop up over time. But the arrogance to say we are picking the best tool for the job, while really picking a tool we wish to use to satisfy ourselves intellectually is what bothers me. If you are forthright and say "Hey, using this will make me happier at my job. And I will thus presumably perform better, and I'm the person in the position to choose what we use" I think that's fair enough. Again, it's the conceit of looking at a business person in the face, and telling them that this tool is the best for the job, when it clearly isn't. It might be the best tool to programatically encode the job. I can concede that. But I feel that is willful blindness on the part of us programmers to the needs of the business in the pursuit of serving ourselves. And again, that bothers me. But you might say "Fair enough, and I was in the position to make that call, so I did". It's not like we exist to serve businesses. But to reiterate for the last time: To say this is being done because it is the best suited for the job at hand is wanting to have your cake, and eat it too.
dasmoth 8y ago
This is a common argument, but I've not seen a great deal of evidence for it on the ground. Rather, there seem to be a decent number of LISP enthusiasts out there who end up working with more mundane languages in their day jobs. If you advertise a LISP position, and make it clear that it really is going to be mostly LISP rather than just a keyword to generate excitement, I can pretty-much guarantee that you'll get applicants. In locations where developers are very thin on the ground (i.e. not Massachusetts...), things might be harder. There's always the possibility of hiring remote.

Yes, but if the hospital ever needs to replace you they are SOL

by Zyst 8y ago

Yes, but if the hospital ever needs to replace you they are SOL

Any developer worth their salt should be able to pick up a new language in a couple days. I'm not sure why some developers are so adverse to learning anything new.

Bootvis 8y ago
I don’t believe it, the internet is full of people that struggle to learn Haskell and even R. For many, it’s not that easy.
- dragandj 8y ago
  But they only need to find one such developer; no need to employ the whole Internet.
eternalban 8y ago
How lucky are you to test your subjective theories [with] someone else's dime.
JamesBarney 8y ago
This just isn't true. There is a reason people look for devs with years of experience in a certain stack.
- mruts 8y ago
  At work we use Scala in a very functional style and Akka. Not a single dev on our team (including me) knew Scala when they started. Everyone was productive with the codebase and programmed idiomatically within a matter of weeks.
  - JamesBarney 8y ago
    I imagine the team was familiar with writing Java, which makes moving to Scala the easiest possible language transition besides maybe a move from C# to VB.NET. Switching to a completely different ecosystem, such as to R, Racket, Haskell and C takes at least twice as long. And could be much longer if you're relying on large framework changes, for instance if you're switching from QT to GTK+ or WPF.
- segmondy 8y ago
  Those developers ain't worth their salt.
  - JamesBarney 8y ago
    Are you arguing that developers graduate and hit maximal productivity in any stack in 3 weeks?
AlexCoventry 8y ago
The language itself, maybe... The ecosystem? Forget it.
nemoniac 8y ago
That's easily said but what's usually meant is that any programmer of a blub language (http://paulgraham.com/avg.html http://paulgraham.com/avg.html) is able to pick up another bulb language in a couple of days. Racket doesn't fall into the category of blub languages.
- spacesuitman2 8y ago
  This. Racket simply allows you to address any problem domain in an even more powerful manner than other Lisp's: simply by creating a truly independent parser and interpreter that still has nice interop with the rest of racket. Not to mention, the metaprogramming facilities are the most advanced in the world.
Zyst 8y ago
I know Scheme, I am currently learning Elm. I like picking up fun languages. I also like working with them when possible. But I think the implication that a hospital board can confidently hire a developer that is "good", or one that will make good decisions in their behalf is wrong. For proof, see the OP of the thread. Their decision, I believe, directly harms the hospital's interests. He has essentially become irreplaceable, because they don't have the necessary skill set to confidently hire someone who will be able to replace them. Even if, in the best of cases, OP leaves for a better paying/what have you job hiring someone to fill their void will be hard. That's not what bothers me most, however. It's the attitude. It's us as developers going: "I picked the best tool for the job, and thus this solution will be intrinsically better for the business". Like we're doing them a favor. We're not doing them a favor, even if the tool is superior for the use case the difficulty of finding other people who could take over you introduces an amount of risk that almost no business that understand the full implications would allow. Worst case scenario, the tool(s) might need to get re-written from scratch. And the new versions could have bugs the old ones don't, or poorly handle all the one million edge cases that pop up over time. But the arrogance to say we are picking the best tool for the job, while really picking a tool we wish to use to satisfy ourselves intellectually is what bothers me. If you are forthright and say "Hey, using this will make me happier at my job. And I will thus presumably perform better, and I'm the person in the position to choose what we use" I think that's fair enough. Again, it's the conceit of looking at a business person in the face, and telling them that this tool is the best for the job, when it clearly isn't. It might be the best tool to programatically encode the job. I can concede that. But I feel that is willful blindness on the part of us programmers to the needs of the business in the pursuit of serving ourselves. And again, that bothers me. But you might say "Fair enough, and I was in the position to make that call, so I did". It's not like we exist to serve businesses. But to reiterate for the last time: To say this is being done because it is the best suited for the job at hand is wanting to have your cake, and eat it too.

dasmoth 8y ago

This is a common argument, but I've not seen a great deal of evidence for it on the ground. Rather, there seem to be a decent number of LISP enthusiasts out there who end up working with more mundane languages in their day jobs. If you advertise a LISP position, and make it clear that it really is going to be mostly LISP rather than just a keyword to generate excitement, I can pretty-much guarantee that you'll get applicants. In locations where developers are very thin on the ground (i.e. not Massachusetts...), things might be harder. There's always the possibility of hiring remote.