5 ms·
1) "The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as a
by pmarreck 4y ago
1) "The founder told me that functional programming is a joke and that I'm clearly a computer scientist and not an engineer, and told me he'd never hire me as an engineer."
This sort of person intends to sleep in the bed that they make, so best to leave them to it.
On the other hand...
2) I'm an Elixir guy looking for work for a few months now. I've been applying to Ruby on Rails jobs where it makes sense (it was a thing I used to do). Should I be concerned that this is the perception out there? IS this the perception out there? I've heard this attitude from businesspeople in the past (such as from Brad Birnbaum, a former boss who is now at Kustomer; this was while I was at Desk.com) at times, "I don't want academics, I want builders". He said this to me repeatedly; in hindsight he was probably trying to signal to me that I was starting to look too academic.
Notably, all of the apps that the businesspeople I've heard say that, are now shut down after being bought out (and Brad is now a bajillionaire after a Meta acquisition). Hmmmmmm. But I guess that was the plan all along: To build only good enough to last to a buyout.
- Yoric 4y agoI'd say that it's all in the eye of the beholder. Not so long ago, everything FP or reactive programming was considered academic. Heck, even virtual machines, garbage-collectors, threads or distributed programming were considered academic. These days, who doesn't use most of these bricks? Which means... sadly, it means that I have no clue what the future holds for Elixir, or Erlang, or any technology that is perhaps a bit too much in advance on its time.
- namaria 4y agoI'm endlessly fascinated by the strong opinions people in software develop about tooling. I never saw it with such intensity anywhere else... I'd like to get more into that someday. Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost...
- pmarreck 4y ago> Maybe because we use these tools with our minds so it's a very intimate thing. Maybe because people find hard to learn a set of tools due to so much of foundational knowledge behind it having been abstracted away so they develop mental defenses against other sets of tools as a rationalization of why they don't wanna lose the sunk cost It is both of those things, I think, and more. For me, at least in Elixir's case having come from Ruby, it is also that I am acutely aware that Elixir virtually eliminates entire classes of bugs that in some cases took me months to run down in Ruby.
- mynameisvlad 4y agoI don’t think it’s a SWE thing at all. Just bog standard human behavior. People like consistency. They hate change. If they get used to a specific tool or way of doing things, I’m pretty sure you’ll find similar behaviors. The key is time spent with a tool. I would expect if you took away an engineer’s favorite CAD software, even if it costs many thousands of dollars, you’d see a similar reaction. Would they be able to do their job with another tool? Certainly. Will you hear about it? Even more certain.
- jemmyw 4y agoI moved away from Rails and then back to it because I really wanted to join a particular company. The answer to 2 is somewhat yes, but Elixir no longer counts. People "build" with Elixir, it's the builders FP. This isn't my opinion (I try not to have one on this subject, fed of language snipes) just the general attitude I've noticed.
- pmarreck 4y ago> Elixir, it's the builders FP I'm really glad to hear that, because to me it does seem like Elixir is the FPL that is closest to satisfying a GSD mentality and not getting caught up in too many interesting rabbit holes.
- glenngillen 4y agoWe (Ockam.io) are definitely building very real and critical things with Elixir. We filled our remaining open position for it last week though so we’re not currently hiring for an Elixir person. Just wanted to point out there’s definitely companies out there that value it for non-academic reasons.
- michaelcampbell 4y agoWhat was your method for hiring; were you looking for Elixir people who can come in hot, or people interested in it specifically that want to learn, or just "good software people" who'd be WILLING to learn it, or something else entirely?
- glenngillen 4y agoI wasn’t the hiring manager for those roles, so I’m not 100% sure. If by “can come in hot” you mean people with existing Elixir experience, then based on who we hired I’d say that previous experience would have been required.
- jononomo 4y agoWhat does GSD mean, please?
- mrkurt 4y agoI think people who are earnest about the sentiment aren't screening specific languages. They're trying to find people who think hard about business problems and follow with implementation. We do this. Our hiring process is impossible to pass for people who fixate on implementation. We have people do a simulated building exercise, and the developers that do well let the user needs drive the implementation. We think we've noticed a correlation between some dev communities and people who lead with implementation. We've seen a little of this with Elixir, but I'm not really worried about it. We've found a number of people who really enjoy Elixir that are also user-first.
- ebiester 4y agoWhen you talk to a manager, you should lead that you are interested in building great products. Even if my company is using functional technologies, I want people who are professionally interested in learning business domains. It's great that you're interested in functional programming, but my fear is that I will hire someone who puts great effort into changing the culture to use avant-garde tech in a place that doesn't provide return on investment. (Or worse, drags us into a culture of malcontent!) That isn't to say Erlang, but I've also seen an organization that struggled to hire because it couldn't find enough Clojure expertise and saw good developers onboard slowly because they had to learn domain, language, and paradigm in a practical environment. There is a secondary worry in hiring people who present as tech-forward: if we need to make pragmatic decisions that mean using industry standard technology, will they leave out of frustration? If we need to make a decision to leave some technical debt there for business reasons and address it later, will this cause difficulties with the developer? ____ (That said, I know a fair number of good developers who have struggled to find work in this environment. It has nothing to do with Elixir.)
- TexanFeller 4y ago> I want people who are professionally interested in learning business domains You can want in one hand, as the saying goes. If you select for people that care about business domains you're more likely selecting people good at feigning interest in your business(aka liars, or otherwise honest people who need to eat). Even if you get what you want you won't do well in the long run. I rarely see people who aren't passionate about technology avoid making a mess of it.
- ebiester 4y agoI have genuine interest in both. I build things because it's awesome to make someone's day better. It's a demotivator for me to put out software that doesn't work well. Technology is a means to that goal. Because I'm wired that way, it's a lot easier to find people who are also wired that way. But I can say that there are absolutely places for people who are wired to be passionate for technology for its own sake. (Some of Fintech and adtech is a good place, for example.) And if you feel you need to lie to work in a place with a product driven culture, then great. But don't be disappointed when the job is listening to calls with users and your conversations are around "which of these approaches will make the user's life better?" and there are technology radars that are justified by users' needs.