I'm certain you could increase the odds of a good hire in all sorts of other ways by seeking correlational stereotypes, but some of those (age, gender, race) would be seen as... very bad, possibly illegal, and some others (traditional-ness of first name, for example) would possibly also work but would be highly questionable. Heck, I bet you could find a correlation with whether or not the person used an AOL email address or not. What makes filtering by this stereotype correlation superior, ethically, to those other stereotype correlations? If "interest in new tech" is an immutable attribute of the person's personality (which it almost entirely likely is), then in both cases you're filtering based on immutable attributes, so they should be considered ethically equivalent on paper, where you have a lot of false negatives, but your "good hire" rate goes up.
> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.
So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.
No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.
How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both.
Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding).
> Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful.
So, me, and everyone I'm interested in working with?
If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.
Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.
Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?
I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.
The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption.
There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors.
Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though.
As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications.
Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.
> #1 priority is reliability
Yeah, mine is too. (In fact, I think we're approaching a crisis of reliability out there, if we're not there already.) That's why I went with Elixir, and it's paid off so far. The only time the site's been down in years is due to my hosting provider, not me... (So of course I'm looking for another hosting provider...) I have to deal with the occasional 500 errors as well, which, as it turns out, are also largely due to my hosting provider and not my code (but sometimes my code...).
The thing I realized about reliability way too late is this: The utility of a service (or a person) to a person drops off VERY quickly if you dip below 99% reliability (or arguably, 99.9% reliability). Something (or someone) that is 90% reliable is practically useless, because it is bound to fail at the worst possible time. So in all the software I write, I focus on this, and in all my relationships with people (or orgs, or bosses, or my son, or my S.O.), I know that if I commit to them, I must be as reliable as humanly possible because the costs of every slip-up are huge and rise exponentially as they accrue.
An example of a service that is just unreliable enough to be a huge annoyance (which has also caused bad communication failures as well in my experience) is SMS. SMS failures are the worst.
But without these, it's like hiring a construction worker who will use any excuse to use a backhoe, even when it isn't suitable, just because they love operating it. It's childish and unprofessional, and as an employer, even if you have full time backhoe work for them to do, you want to avoid hiring them, because they'll probably cause a lot of damage to your building site driving the backhoe everywhere when a wheelbarrow would have been more suitable.
Elixir is great for massively parallel web facing problems, and if you can explain it as a tool you have in your toolbox for solving this kind of problem then great. But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.
In the past, when I really wanted to try something and the boss didn't agree with spending work time on it, I spent my weekend time on it (back before I had a kid- Seems like a luxury, now!). Most of the time, I came up with something I could demonstrate on the following Monday which got accepted. Sometimes, it didn't, or my hunch/effort was unsuccessful (but I wasn't unhappy because at least I tried).
uhhh, so Elixir is a general purpose language that solves everyday problems. and just happens to havethis phenomenal almost "no-code" solution to literally the problem you just presented, with Elixir Livebook.
...
The VM is 35 years old. The syntax is Algol inspired, the Elixir syntax is 10 years old, FP as a paradigm has been around since 1958.
It's not some new and shiny toy, it's simply unfamiliar to you.
That is pretty far from what I said. Try again?
> One kind of bad hire is the technology-lover who values their own preferences over the needs of the business.
OK. This is not a mutually-exclusive relationship. One can prioritize both of these; the best team player will prioritize the needs of the business (and the team) more, however. This to me seems like you're really addressing the problem of "vanity/primadonna devs" who are not team players, and not just devs who really like certain technologies which will possibly blind them.
I also think experience tempers this quite a bit. I've certainly had dev experiences where I became enamored with an idea or trendy tech, felt I absolutely had to implement it, and then ended up regretting it later. I think this happens a lot with younger devs and that's OK because that's how you learn. (Make sure they get assigned the mess cleanup when it doesn't work out though. LOL)
Sounds like they hired people unqualified to take over product maintenance.
If your engineers can’t wrap their head around ”FP-ish” JavaScript, they’re not exactly batting .300.
I don't think it's unreasonable for average Javascript programmers to look at that and say, "WTF", the same way that they'd look at code from somebody who wrote C in Javascript.
E.g., a friend of mine took over a team with a couple of strong FP advocates on it. They had written a core tool in very FP-ish JS. They enjoyed the novelty of the greenfield work, but once it was down to just making the changes users needed, they got bored and moved on. The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque. Either way, they eventually had to rewrite it.
Or personally, I have made a lot of good money coming in after some would be brain genius, ripping out their supposedly cutting edge work, and replacing it with something boring. I remember one place where a core part of a system was build on the 0.7 version of then-fashionable technology. Except it wasn't even 0.7 as released, but something with custom patches applied. None of the people there could maintain it. Looking at git blame and doing a little web searching, it turned out the developer responsible had then done a self-promoting conference talk about their amazing work, and then quit shortly thereafter. After I removed it and replace it with something much simpler, not only could the people there maintain it, but it worked better than before.