Live data from Hacker News

The Functional Programming Hiring Problem

blog.janissary.xyz

81–90 of 140 posts

Re: The Functional Programming Hiring Problem

#81
post #3

> The multi-armed bandit is a really interesting problem in mathematical optimization... This problem is so interesting, in fact, that during World War II the Allies proposed air dropping copies of the original paper over Germany. The end result, or so it was theorized, was that German scientists would be so fascinated and distracted by the problem that they would abandon the war effort and cripple any German militar…

It's so incredible you should not believe it. Multi-armed bandits were introduced in the 50s, years after the end of World War 2.

Pulling from this published source[0]:

> As I said, the problem is a classic one; it was formulated during the war, and efforts to solve it so sapped the energies and minds of Allied analysts that the suggestion was made that the problem be dropped over Germany, as the ultimate instrument of intellectual sabotage.

[0]: https://academic.oup.com/jrsssb/article-pdf/41/2/164/4909740...

Re: The Functional Programming Hiring Problem

#82
post #3

> The multi-armed bandit is a really interesting problem in mathematical optimization... This problem is so interesting, in fact, that during World War II the Allies proposed air dropping copies of the original paper over Germany. The end result, or so it was theorized, was that German scientists would be so fascinated and distracted by the problem that they would abandon the war effort and cripple any German militar…

It's so incredible you should not believe it. Multi-armed bandits were introduced in the 50s, years after the end of World War 2.

[deleted]

Re: The Functional Programming Hiring Problem

#83
post #4

This is just a hiring problem, not related to functional programming. I agree with the basic premise of the article however: depending on the financial condition of the company, hiring people who are overly attached to or obsessed with a single technology probably isn't a good idea. But that's of course not exclusive to functional programming. Right now you will find plenty of people obsessed with Rust (not a functio…

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.

This is the very first thing I do when picking up a new tech - language, framework, library, tool. After initial familiarization with the basics - Wikipedia/Readme-Intro, I would google "Why does X sucks", and try to avoid becoming overly enamored with it too quickly, and strive to maintain a level-headed perspective.

Re: The Functional Programming Hiring Problem

#84

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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 ben…

It’s a spectrum, it’s multidimensional and it changes over time though.

I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece of elegant code against the pleasure of positive business outcomes. I think that makes me neither a “boring business person” nor a diehard code nerd, but somewhere at the intersection with attributes in other directions not captured by either stereotype.

That said, if you really are 100% motivated by abstract technical challenges, then maybe academia is more for you than industry is. Or working at the small slice of companies that truly make their bread and butter on cutting edge technical excellence and not, say, applying tried and true tools to some underserved niche.

I do find the “algorithm nerd” charisma also tends to intersect with having warped views of how the world operates and weak self-awareness, so maybe easier said than personally realized.

Re: The Functional Programming Hiring Problem

#85

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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 ben…

> 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.

Re: The Functional Programming Hiring Problem

#86

The classic story is how pg created a storefront in lisp that he sold to yahoo. Yahoo couldn't hire lisp programmers and rewrote it in another language (c++?) and it wasn't as good. But the decision still made sense from a business perspective. And this article sadly shows why. Objectively, they aren't fair to "Goody engineers". Often, they mean opinionated engineers . Now opinionated engineers can be good and bad fo…

Reminds me also of Figma converting all of their custom language stuff into Typescript, even though Typescript is slower.

Re: The Functional Programming Hiring Problem

#87
post #67

>Are you sure you aren’t just using Gooby because it is fun? No. I don’t do anything (by choice) if it is not fun.

Exactly this. I'm indifferent to the most popular, ubiquitous, top-10-on-every-X-list trends. It's a pattern: something gains massive adoption only to fizzle out a few years later. XML, the one-size-fits-all OOP, all-in microservices, Silverlight, Flash, etc.

Usually, there are some good, pragmatic reasons why something gets selected, and it is always accompanied by trade-offs. The decision is not mine alone to make; we need buy-in from everyone on the team. If the choice turns out to be not very delightful or fun, it becomes obvious - replace it. My initial reaction to the question "Why are you using Gooby? I've never even heard about it..." is always "because it's fun"

And it is absolutely normal to become a team where everyone enjoys Gooby, and they'd try to hire like-minded people.

Re: The Functional Programming Hiring Problem

#88

This is a problem that extends far beyond “esoteric language of choice”. It’s the challenge of being a nerd in a boring business world. 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 ben…

It’s a spectrum, it’s multidimensional and it changes over time though. I love myself computers and probably more so earlier in my career than now, but I also like influencing people (often through code, with a focus less on algorithmic elegance but instead more on setting patterns, tooling, and APIs that influence how others build around them); and I also enjoy the challenge of aligning the pleasure of a juicy piece…

Hello! I'm just starting my career as a dev now and I am definitely more drawn to academia and research than to the business world. Could you point me to some resources where I can learn more about companies or projects that work researching CS/programming topics?

Thank you in advance.

Re: The Functional Programming Hiring Problem

#89
I've been on several sides of this issue. I've been using Haskell for around 16 years, and I currently work on a product that's written almost entirely in Haskell on the backend. I've worked in a variety of languages throughout my career, and I've taken plenty of jobs that involved no FP at all, jobs that involved a mix of languages, and some that were primarily Haskell.

I've certainly seen people in the Haskell teams I've worked on who fit the article's description of people who were there to write Haskell and didn't care about much else. It didn't go great, but they were a minority of the people I've worked with.

Importantly, I've also seen plenty of that kind of behavior in other teams using other tech stacks. I've worked with "Agile people" whose answer to every problem is pair programming. I've worked with people who only care about microservices, or their favorite frontend framework. I've worked with people who see more object orientation as the solution to every problem more often than I've seen people who want to apply FP to every problem.

A few of these people can be find to have on a medium or larger sized team- if the worst of their instincts are tempered they can be a great source of internal education and advocacy, and they can bring expertise that can help you deal with the inevitable problems and tradeoffs that come with any technical choice. You just need to be careful to, on balance, have a team of mostly product-minded people.

Product people aren't necessarily tech-stack agnostic. To use myself as an example, I really like functional programming and I think it's often a good technical choice. At the end of the day though, my job is a job and I'm there to build the best product I can to make my employer (and myself) money. I've turned down Haskell jobs because I didn't believe in the product or team, and taken jobs in less preferred tech stacks because I did. A lot of people can be both enthusiasts and pragmatists, you just need to look for them.

I think one of the biggest issues I have with the article is that it overlooks a significant source of hiring: product minded people who are open to, but not specifically enthusiastic about your tech stack. People don't need to be an FP enthusiast to work in a functional language. I've written a lot of Python and Go in my career, even though neither of them are my favorite language. By the same token, there are plenty of people who can work with Haskell, OCaml, or a lisp just fine with a bit of training even if FP isn't something they are going to devote themselves to. I've worked with a lot of people who do Haskell in their day job, but prefer to spend their free time using Rust.

None of this is to say that everyone should go out and use an FP language. I think the most important factor in picking a language is generally going to be picking something that your team likes and understands well. Most languages are good enough at most problems that individual preference is going to matter more than technical concerns. If Haskell or OCaml or Gooby is that preferred language for your team, I don't think you should avoid it.

Re: The Functional Programming Hiring Problem

#90

The way I see it, functional programming converts are often people who failed to properly grasp other, more challenging methodologies and decided that they need training wheels on their bikes. Though they won't frame it that way of course; they'll say that other methodologies lack the 'proper guardrails' which is telling... I'm yet to meet an FP fanatic who actually properly understood OOP. Few seem to even understan…

> they're often people who are incapable of taking something complex and simplifying it.

Excuse me? Haven't a ton of things in recent years been simplified by borrowing ideas from FP? LINQ in C#, Flask route decorators in Python, React Hooks and Redux reducers, Rx in Angular, Kafka streams, and more?

> Few seem to even understand the core principles

They do understand specific pain points experienced outside of FP - side effects, mutable state, uncontrolled complexity. Many FP proponents are well-versed in OOP but choose FP for reasons like simpler state management, declarative syntax, and powerful concurrency models.

> They're people who can't keep complexity under control

> they're often people who are incapable of taking something complex and simplifying it.

FP langs specifically provide advantages for easier reasoning about code, deterministic functions, and improved reusability. Why would someone willingly want to try and take control of exploding complexity if they have already know better tools to manage it? Tools that they understand more thoroughly and that feel more "natural" to them, closely aligning with mathematical function theory. Math is already one of the best tools for describing a vast number of things in the entire universe. Why would anyone who understands math want to go study some other voodoo-doll piercing technique, even if it claims to be particularly effective at solving specific problems?

Post reply on HN