4 ms·

I think the solution is to stop looking for people with explicit experience in Haskell (or any lang), and to simply take on friendly and open-minded individuals

I think the solution is to stop looking for people with explicit experience in Haskell (or any lang), and to simply take on friendly and open-minded individuals to be trained internally. Even cleverness doesn't have to be a criterion; if you're doing FP right, you shouldn't need to be too smart. I'm certainly not. I was fortunate enough to be hired in this manner, and I'm always more than happy to help train up new members in a similar fashion. It pays off in the long run—and the short run too, since it doesn't take that long to get somebody playing with Maybes and Eithers in some internal module.

dmitriid 5y ago
> simply take on friendly and open-minded individuals to be trained internally. "simply". So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?
- jim-jim-jim 5y ago
  Production and training aren't a binary. It's realistic enough to have a couple of senior devs write the scaffolding that segregates the nasty details, then have junior devs pair with them on the more logically pure modules. As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. I've been on both sides of the equation and it works quite well in the long run.
  - dudul 5y ago
    Playing devils advocate: sounds pretty complicated. We'll just use Javascript and have access to an ever growing pool of cheap devs. Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.
    - dmitriid 5y ago
      It's not just "c-suite execs". If our department has 60 devs across 5-10 teams, the cost of "simply" bringing in people who don't know the language and expecting to both onboard them to business and teach them a new language becomes astronomical
    - jim-jim-jim 5y ago
      I guess I'm not just speaking in favor of language x, but a broader culture of knowledge sharing, pairing, and educational development that naturally supports languages like x. I realize this is anathema to slavedrivers, but it can and does work.
  - dmitriid 5y ago
    > As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. What about "a big company with multiple dev teams that are expected to actually deliver things on time"?
    - jim-jim-jim 5y ago
      I work for a large firm (hundreds of engineering staff) that invested in strongly-typed FP. We deliver things on time because we're not putting out fires caused by stupid runtime errors. There's more than enough time to teach the juniors along the way too. Once again, education is a ultimately a facet of productivity, not something that detracts from it.
      - StefanWestfal 5y ago
        Which languages are you using if I may ask? I was looking at Haskell and Elm and some repositories show little activity. Was the ecosystem a problem for you?
        jim-jim-jim 5y ago
        Haskell, Scala, Typescript, and Purescript. Ecosystem is better with Scala, but hasn't been too much of a problem in any of them, perhaps because we try to avoid too many dependencies.

dmitriid 5y ago

> simply take on friendly and open-minded individuals to be trained internally. "simply". So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?

jim-jim-jim 5y ago
Production and training aren't a binary. It's realistic enough to have a couple of senior devs write the scaffolding that segregates the nasty details, then have junior devs pair with them on the more logically pure modules. As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. I've been on both sides of the equation and it works quite well in the long run.
- dudul 5y ago
  Playing devils advocate: sounds pretty complicated. We'll just use Javascript and have access to an ever growing pool of cheap devs. Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.
  - dmitriid 5y ago
    It's not just "c-suite execs". If our department has 60 devs across 5-10 teams, the cost of "simply" bringing in people who don't know the language and expecting to both onboard them to business and teach them a new language becomes astronomical
  - jim-jim-jim 5y ago
    I guess I'm not just speaking in favor of language x, but a broader culture of knowledge sharing, pairing, and educational development that naturally supports languages like x. I realize this is anathema to slavedrivers, but it can and does work.
- dmitriid 5y ago
  > As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. What about "a big company with multiple dev teams that are expected to actually deliver things on time"?
  - jim-jim-jim 5y ago
    I work for a large firm (hundreds of engineering staff) that invested in strongly-typed FP. We deliver things on time because we're not putting out fires caused by stupid runtime errors. There's more than enough time to teach the juniors along the way too. Once again, education is a ultimately a facet of productivity, not something that detracts from it.
    - StefanWestfal 5y ago
      Which languages are you using if I may ask? I was looking at Haskell and Elm and some repositories show little activity. Was the ecosystem a problem for you?
      - jim-jim-jim 5y ago
        Haskell, Scala, Typescript, and Purescript. Ecosystem is better with Scala, but hasn't been too much of a problem in any of them, perhaps because we try to avoid too many dependencies.