4 ms·

Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is t

Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. 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.

pmarreck 4y ago
> Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. 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.
- snovv_crash 4y ago
  > 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.
  - mynameisvlad 4y ago
    > 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. 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.
    - snovv_crash 4y ago
      > How does that sentence show that, exactly? 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.
catiopatio 4y ago
> 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. 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.
- seattle_spring 4y ago
  There’s plenty of code that can be so complicated that it becomes easier to rewrite versus understand. I worked with a coworkers who made the most absolutely spaghetti-like JS modules, insisting on event emitters and queues and stuff like that for even the most basic tasks. The result was an incomprehensible mishmash of events shooting from file to file to file. Touching how these events were handled in some way might destroy how they were interpreted for completely different tasks, it was wild. It’s very possible that the code in question wasn’t just opaque because it was “FP-ish”, giving the parent the benefit of the doubt.
  - snovv_crash 4y ago
    Exactly. Code that is too asynchronous with lots of pubsub basically turns into GOTOs with data - there's no way to trace the execution step by step.
    - Kamq 4y ago
      At least gotos generally tell you where they're going.
- wpietri 4y ago
  Depends on what you mean by "FP-ish". I never saw this code, but the way this was described to me as high church FP, the kind of people who really wanted to be working in an ivory tower FP language and so had coded as if that's what they were using. 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.
duxup 4y ago
I feel like we just went back from “it doesn’t matter need to filter somehow” back to “it matters”.

pmarreck 4y ago

> Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. 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.

snovv_crash 4y ago
> 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.
- mynameisvlad 4y ago
  > 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. 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.
  - snovv_crash 4y ago
    > How does that sentence show that, exactly? 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.

catiopatio 4y ago

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

seattle_spring 4y ago
There’s plenty of code that can be so complicated that it becomes easier to rewrite versus understand. I worked with a coworkers who made the most absolutely spaghetti-like JS modules, insisting on event emitters and queues and stuff like that for even the most basic tasks. The result was an incomprehensible mishmash of events shooting from file to file to file. Touching how these events were handled in some way might destroy how they were interpreted for completely different tasks, it was wild. It’s very possible that the code in question wasn’t just opaque because it was “FP-ish”, giving the parent the benefit of the doubt.
- snovv_crash 4y ago
  Exactly. Code that is too asynchronous with lots of pubsub basically turns into GOTOs with data - there's no way to trace the execution step by step.
  - Kamq 4y ago
    At least gotos generally tell you where they're going.
wpietri 4y ago
Depends on what you mean by "FP-ish". I never saw this code, but the way this was described to me as high church FP, the kind of people who really wanted to be working in an ivory tower FP language and so had coded as if that's what they were using. 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.

duxup 4y ago

I feel like we just went back from “it doesn’t matter need to filter somehow” back to “it matters”.