Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Functional Programming Hiring Problem

blog.janissary.xyz

Post reply on HN
Print view View original

101–110 of 140 posts

Re: The Functional Programming Hiring Problem

#101

Post by throwawaymaths »

nicce wrote: post #80
throwawaymaths wrote: post #74

I'm actually suffering from the opposite problem. CTO is a well known Gooby developer. But we wrote everything in C++ because "it will be easier to hire down the line", pulling in well known C++ libraries by various bigcos that actually don't compose together and make a royal mess of the codebase. We've missed every single deadline, and are light years behind where we should be. Honestly we should have written it in…

Now, the correct comment in this context; why not Rust?

I shudder to think of the levels of architecture astronaut that the CTO would rise to if we put rust in his hands

Re: The Functional Programming Hiring Problem

#102

Post by kazinator »

Here is the problem in the article: nearly every language is going to have the (3) people.

Hire people for embedded C and you will run into some some people to whom C programming and their side projects in it are more important than whatever you're trying to ship.

Substitute anything. Rust, C++, Ruby, Java, ...

And of course the resume stuffing (1) people are also a language-independent problem.

Certain languages probably won't have too many people in the (2) category (excited recent grads). But those are the good candidates in relation to (1) and (3), according to the Gooby analysis in the article.

Re: The Functional Programming Hiring Problem

#103

Post by warcher »

aleph_minus_one wrote: post #53
warcher wrote: post #37

Earlier quoted context omitted.

At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently. Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done. I do get cau…

> At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less. When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programmin…

The ideas begin to repeat after a while. I’m a bit of a rolling stone. Most folks tend to specialize but I get bored easily.

Re: The Functional Programming Hiring Problem

#104

Post by anonzzzies »

ebiester wrote: post #85
aleph_minus_one wrote: post #57

Earlier quoted context omitted.

> What attracts people to being a programmer? For some people it’s “looks like a reasonable job with good pay and conditions”. For others, it’s more “I love computers, programming, and abstract puzzles to solve”. This latter group (of which I am one), is more likely to provide both benefits and problems. > The benefit is they will generally be capable of greater innovation than the former group, but the downside is t…

It’s simpler. Business people hate paying people for any other reason than making more money.

Yep, the ‘nerd’ analysis of something that is very trivial is funny really. It’s money: most business peeps don’t give a crap about you or your skills: they pay the minimum they can to up the gains and that’s it. No more complex explanations are needed.

Re: The Functional Programming Hiring Problem

#105

Post by Const-me »

BeetleB wrote: post #71
jballanc wrote: post #68

Earlier quoted context omitted.

This is why one of my favorite series of questions to pull out during an interview are: What is your favorite programming language/library/technology? What do you hate about it? Anyone that jumps to answer the first but struggles to answer the second is likely not someone you want to hire.

Ok. For anyone struggling with the second, the answers should be: Lack of libraries. Lack of good tools.

My favourite languages are C# and C++, and sometimes I interview developers to work with them. Saying these languages are lacking libraries or good tools is unreasonable.

Re: The Functional Programming Hiring Problem

#106

Post by anonzzzies »

nextaccountic wrote: post #100
wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

I don't see why anyone should be a $LANG dev. All programming languages suck (there is this theoretical language that doesn't suck, but it isn't invented yet). Surely $LANG devs recognize that their language sucks, right? And that's why we switch languages constantly. For some problems, some languages suck a little less.

> And that's why we switch languages constantly

I only have one life and I prefer not to suffer too much; switching languages is not helping me at all in preventing that suffering.

Re: The Functional Programming Hiring Problem

#107

Post by _xiaz »

Great post and very relatable. I too had my phase with a month of Haskell and then many more with Clojure. Even some other lisp exploration. It's a lot of fun, but I've since come to terms that from a career and business perspective I'm better off writing Python or Shell. (I'm a Infra/Devops guy, if it matters)

Re: The Functional Programming Hiring Problem

#108

Post by anonzzzies »

wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

> You wouldn't have this problem in the first place if the language you chose -did- have an actively maintained JWT library.

Actively maintained does not mean it’s good. We have to read and fork all libs we use (regulatory) so it won’t end up getting hacked etc, at least, less likely and a lot of ‘actively maintained libraries’ especially npms/pips are total garbage. We often spend less time just rolling ourselves than figuring out if this unreadable, overarchitected resume driven garbage even works.

Re: The Functional Programming Hiring Problem

#109

Post by _xiaz »

nextaccountic wrote: post #100
wavemode wrote: post #11

The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand". To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think. From the article: > Then, one thing leads to another, and you're knee deep in learning…

I don't see why anyone should be a $LANG dev. All programming languages suck (there is this theoretical language that doesn't suck, but it isn't invented yet). Surely $LANG devs recognize that their language sucks, right? And that's why we switch languages constantly. For some problems, some languages suck a little less.

I agree with your sentiment for the inverse reason.

Most programming languages are pretty neat. Learning is a joy. That's why language hops are fun and common.

But yes, few things make me cringe more than someone selling themselves short by introducing themselves as a $LANG dev

Re: The Functional Programming Hiring Problem

#110

Post by mike_hearn »

PheonixPharts wrote: post #20

Is this written from a different time line were TypeScript doesn't exist? I have a long history of doing FP in a bunch of the traditional FP languages (Scheme/Haskell/etc). Ended up working at a young startup with equally young employees awhile back and was sort of surprised to see that the long heralded fantasy of cranky FP enthusiasts has, for better or worse, come true in Type Script. I saw a generation of new pro…

That's not a TypeScript issue. I've encountered the same problem of not testing things properly in other languages. There's a definite mindset amongst some programmers that if it compiles and the unit tests pass, then it must work. I think a lot of less experienced devs have read too many blog posts on PL theory/testing and don't realize how many bugs are just not going to get caught by such techniques. You really do have to see something work with your own eyes and hammer it for a while by hand to know it's of a decent quality.

The fear of OOP is a problem though. I've encountered some really bad TypeScript/JS codebases that were just piles of top level functions for everything. The meme that OOP is bad is really damaging.

Post reply on HN