4. They're SREs/PEs who mastered concepts in breadth of many languages and depth down the stack. Some us are even EEs who can do EDA work too for your custom hardware devices and write custom kernel modules.
The Functional Programming Hiring Problem
41–50 of 140 posts
Re: The Functional Programming Hiring Problem
#42Re: The Functional Programming Hiring Problem
#43The 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…
The problem is not with opinionated engineers. (Almost every engineer I know is opinionated; the ones who are not tend not to be very good.) The problem is with engineers who are excessively opinionated about the wrong things. Having opinions about the product is way more valuable than being obsessed with writing the umpteenth JSON parsing library in Gooby because the others aren’t built exactly the way you’d build it.
Re: The Functional Programming Hiring Problem
#44One of brooks's papers (the guy that brooks's law is named after) is about how software developers would rather write the tools to solve the problem and then solve the problem itself. A fair amount of this article is observing this problem persists 60 years later.
> how software developers would rather write the tools to solve the problem and then solve the problem itself.
That's because you know you'll be stuck with maintaining the solution. Nowadays, we have resume-driven people that just build stuff without any care as they know they're only here for two or three years.
Re: The Functional Programming Hiring Problem
#45Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers. But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.
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.
This is the right attitude
Re: The Functional Programming Hiring Problem
#46> 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…
Sounds like an impractical (and ineffective) idea that was never implemented, so not actually all that incredible. Rather boring, inconsequential anecdote that adds nothing to the discussion.
Something can be inconsequential and yet still interesting/amusing
Re: The Functional Programming Hiring Problem
#47The author brings up some good points here, but I would just make sure to build my business around trading obscure financial instruments in a clever way, so as to generate such an overwhelming amount of profit that we can singlehandedly rewrite and maintain everything in our stack from scratch. I acknowledge, however, a lot of people never think to do this when starting their business, and consequently run into all s…
Is this a reference to one particular company/language?
Re: The Functional Programming Hiring Problem
#48In 2005, I needed to hire a Haskell dev with deep NLP expertise to replace a member of my startup team. After a posting on the Haskell mailing list, zero responses came back. We realized the world had about 3 people that matched all the requirements: one was the dev that needed to be replaced, the other one was a tenured professor of a U.S. university (Hi, Hal!), and there was one more, whom I don't remember but it m…
I'm always surprised when I see this approach to hiring. I have a lot of Haskell in the codebase at my current company. It hrs never occured to me to try to hire from the "Haskell community" we always hire from our product community because tech is easier to teach than product.
Re: The Functional Programming Hiring Problem
#49The 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…
Interesting take and it feels familiar. I'm definitely in the "I need a tool to keep complexity under control" camp but I don't see it as a bad thing. Coming from a support and sysadmin/ops position seeing the same kind of problem every time makes you want to avoid the problem class. Of course it's often a fantasy. However I realized most problems I experienced were due to a general lack of understanding of the tools and concepts used. This was Java, Spring Framework, Aspect Oriented Programming and an ORM wrapper (MyBATIS) and 99% of my ops problems were due to the devs working around and against these concepts and tools with lots of bad code and so many NPE's that I still get nightmares. A skilled crew of veterans familiar with i.e. Spring, MyBATIS could have refactored this in a few months and most problems would be gone just using each tool how it was meant to be used. But we only added poorly understood layers upon poorly understood layers...
I understand everyone that goes into functional programming after realizing classes of problems don't exist there. I like guardrails. I learned to like immutable functional data structures after realizing 70% of time is Java serialization in the flame graph and I'd rather had the clojure way of solving these problems instead of the hidden magic. But properly learning all the mentioned tools and not abusing them would be enough.
Re: The Functional Programming Hiring Problem
#50Earlier quoted context omitted.
Sounds like an impractical (and ineffective) idea that was never implemented, so not actually all that incredible. Rather boring, inconsequential anecdote that adds nothing to the discussion.
Something can be inconsequential and yet still interesting/amusing
Is it amusing that someone suggested an impractical and ineffective idea once? There are billions more where that came from.