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

Haskell in Production: Standard Chartered

serokell.io

Post reply on HN
Print view View original

161–167 of 167 posts

Re: Haskell in Production: Standard Chartered

#161

Post by kerkeslager »

riwsky wrote: post #139
ParetoOptimal wrote: post #121

Earlier quoted context omitted.

> If a candidate is primarily interested in your company because of your particular tech stack, they are probably the wrong candidate. I disagree. I believe that most candidates are likely only interested in your salary, benefits, or other things not relevant to what your company does. A necessary state of affairs where worker rights and worker loyalty don't count for much in the face of the horribly named "right-to-…

I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really…

If you're working at a for-profit corporation, "the mission" is "money", so there's no distinction between "here for the mission" or "here for the money". Anyone who says otherwise is either naive about what the mission is, or lying (which I can't blame them for, because that's often the politically savvy move). Exceptions exist, but they're temporary because competition usually kills them.

Sadly, the mission is often money at nonprofits as well, because capitalism won't let you survive without it. But the "here for the mission" folks skew a lot more toward the "naive" side of the spectrum than the "lying" side. Again, exceptions exist.

Re: Haskell in Production: Standard Chartered

#162

Post by riwsky »

ghostwriter wrote: post #153
riwsky wrote: post #139

Earlier quoted context omitted.

I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really…

> I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. How is "being there for the mission and for the people" better than "being there for money and for tech stack"? The latter also has to do with people and missions, only the missions and the people are important and related to the candidate directly, and not through company owners' or hiring manage…

> How is "being there for the mission and for the people" better than "being there for money and for tech stack"

Tech stacks change; human stacks stay the same. Intellectual honesty isn't going to obsoleted by some shinier virtue in 5 years—and if a company needs to pivot, it's still going to be a right tool for the job.

Re: Haskell in Production: Standard Chartered

#163

Post by riwsky »

kerkeslager wrote: post #161
riwsky wrote: post #139

Earlier quoted context omitted.

I agree that “here for the tech stack” is generally better than “here for the money”, but I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. It’s also really hard to blame people for being there for the money when, hey, we don’t know what kind of student loans or life financial situation they have. And when you don’t know a domain or company really…

If you're working at a for-profit corporation, "the mission" is "money", so there's no distinction between "here for the mission" or "here for the money". Anyone who says otherwise is either naive about what the mission is, or lying (which I can't blame them for, because that's often the politically savvy move). Exceptions exist, but they're temporary because competition usually kills them. Sadly, the mission is ofte…

I was on the naive side, you're not being unfair!

Re: Haskell in Production: Standard Chartered

#164

Post by riwsky »

aranchelk wrote: post #148
riwsky wrote: post #138

Earlier quoted context omitted.

> It’s not the candidate’s job to be interested in your company. As a founder, leader, or even hiring manager it’s your job. It’s my job to do that for the right candidates . Positive working environment, caring about employee growth, long term goals—all these things you mention are extremely important, and they are what we should be competing on. If an engineer would forgo an opportunity that provides those just so…

Surely there must be some lower bound of technology after which a candidate can be completely excused for turning down a job regardless of the factors you have said should be their criteria. Examples: Perl, COBOL, or punch cards.

There is—at which point you need to find candidates primarily by their willingness to work with your tech stack, which means you probably have the wrong tech stack. It's not like leadership at punchcard-dependent firms disagree, and think their tech stack is great; they just can't switch that choice on a dime, and often need those punchcard experts specifically for the get-of-the-punchcards effort.

Re: Haskell in Production: Standard Chartered

#165

Post by ParetoOptimal »

riwsky wrote: post #162
ghostwriter wrote: post #153

Earlier quoted context omitted.

> I’ve just been fortunate enough to work in situations where people were there for the mission and there for the people. How is "being there for the mission and for the people" better than "being there for money and for tech stack"? The latter also has to do with people and missions, only the missions and the people are important and related to the candidate directly, and not through company owners' or hiring manage…

> How is "being there for the mission and for the people" better than "being there for money and for tech stack" Tech stacks change; human stacks stay the same. Intellectual honesty isn't going to obsoleted by some shinier virtue in 5 years—and if a company needs to pivot, it's still going to be a right tool for the job.

Typically tech stacks don't change for good reasons, just subjective reasons.

Why should I value the subjective decision of some new engineering manager that decided the tech stack should change so they can pad their resume?

Even if I'm there for the mission, this would give me pause.

If I was there for the tech stack alone, I'd quickly be looking for a new job.

The central point you seem to be making is "hiring for people there for the mission means employees friendlier to company changes/pivots". This feels valid, however the tech stack could affect execution of the mission. Or a given person could just hold the opinion that tech stack affects execution of the mission.

I guess my counter-argument to that then is it's not such a straight-forward win.

However my views are that tech stacks and programming languages matter a lot more than most give them credit for. See:

It's not what programming languages do, it's what they shepherd you to https://nibblestew.blogspot.com/2020/03/its-not-what-program...

So it's easy for me to recoil to hearing "right tool for the job" cargo-culted without real arguments justifying the comment.

Circling back to the central point, I do think I would bias towards hiring people that seem "there for the mission". I believe many people would probably be just pretending though, so it's not that great of a postive signal imo.

However we may differ in that I don't think I'd heavily avoid hiring people "there for the tech stack" any more than I'd try (and fail) to avoid hiring people "there for the money".

Re: Haskell in Production: Standard Chartered

#166

Post by riwsky »

ParetoOptimal wrote: post #165
riwsky wrote: post #162

Earlier quoted context omitted.

> How is "being there for the mission and for the people" better than "being there for money and for tech stack" Tech stacks change; human stacks stay the same. Intellectual honesty isn't going to obsoleted by some shinier virtue in 5 years—and if a company needs to pivot, it's still going to be a right tool for the job.

Typically tech stacks don't change for good reasons, just subjective reasons. Why should I value the subjective decision of some new engineering manager that decided the tech stack should change so they can pad their resume? Even if I'm there for the mission, this would give me pause. If I was there for the tech stack alone, I'd quickly be looking for a new job. The central point you seem to be making is "hiring for…

I think where we're ending up here is that—while all these points ("tool for the job", "here for the mission") may be true—they are often cited by people who are full of shit, so seeing them in job postings, interviews, etc doesn't really send any useful signal.

Re: Haskell in Production: Standard Chartered

#167

Post by rovolo »

kerkeslager wrote: post #160
JonChesterfield wrote: post #62

Earlier quoted context omitted.

This reply neatly captures that functional programming tends to consider performance/efficiency in terms of number of reductions. Sadly other programmers tend to view it as wall clock time and the two don't correlate very well.

Sadly? If a client comes to me and says one of the parts of their application was slow, and I come back to them saying I lowered the number of reductions with zero change in the wall clock time, they'll fire me, and rightly so .

To be nitpicky, wall clock time isn't the same as CPU time or power draw. You can increase efficiency at the same time as you increase wall clock time because they aren't necessarily the same metric.
Post reply on HN