4 ms·

I hire based on ability/intelligence, not knowledge.

andrewstuart 3y ago
>> I hire based on ability/intelligence, not knowledge. Well, yeah that's really your only choice if the experience you need is not easily available. Don't tell me, you are the guy who puts in the not mainstream technology and needs to defend that with justifications such as "when we use (non mainstream technology X) we get super motivated job applicants because anyone with an interest in non mainstream technologies is inherently passionate and interested". That's not a sound hiring strategy.
- inopinatus 3y ago
  And you are the guy who left Visual Basic, COBOL, Perl, and FORTRAN off their "obviously safe choices for hiring in the future" list, despite them all having once been perceived as such. These inconvenient counterexamples blow up the entire thesis. In practice, the "safe choice" for longevity is only evident in hindsight. If anyone is hiring for TypeScript in 2050 I'll eat my hat
  - h0l0cube 3y ago
    I'm in sympathy with your main argument, but given that people still, in 2023, hire for COBOL, a language made in 1959, makes me think you'll be eating your hat.
    - inopinatus 3y ago
      Notwithstanding that I'm effectively forecasting the decline & fall of TypeScript as javascript-flavour-of-the-month, note that I shrewdly also granted myself the better part of three decades to launch an edible headwear startup
      - claytongulick 3y ago
        Most of the perceived value that Typescript brings will probably fade once js gets type annotations [1], though Typescript will always have more advanced syntax and capabilities. There are interesting discussions about Typescript becoming more of a run-time type checker, which would be opt-in and have significant performance penalties, but would give more guarantees of type safety. [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations
calvinmorrison 3y ago
This sounds fun until your entire stack is on Perl in 2023 (which, is fine-ish when your CTO was the perl project lead). But then you have a bajillion dependencies that aren't really updated anymore, you end up owning most of the Mail::Toolkit libraries, etc. and nobody really knows perl that well. I mean, a lot of us can jimmy around in Perl, but of the real Perl Gurus in the world, you will end up hiring 50% just to keep your company going
ttymck 3y ago
I think I'm rather able and intelligent, but there are just so many footguns in golang that my team doesn't have the knowledge to avoid.
- drzaiusx11 3y ago
  Just curious, what are some of those footguns your team is encountering? Only thing that comes to mind is the somewhat tedious error handling imposed by the language. Which language would you say had _less_ footguns than go? Or was this sarcasm and it went straight over my head?
  - ttymck 3y ago
    I guess I am just bad at golang. Loop variable pointer and nil struct is not nil interface are the two that continue to hound us.
    - ttymck 3y ago
      Also: type MyError {} var _ error = (&MyError)(nil) errors.As(err, &MyError{}) --- Panicking because it needs to be &&MyError{} instead is a similar gotcha.
drzaiusx11 3y ago
"Ability" by itself is a bit vague here, but I will say that having a proven trackrecord in their ability to learn is something I specifically look for in a candidate. Not only learning new tech, but also learning from mistakes and experiences over time. However, I don't think raw "intelligence" is the right metric for hiring. Unless you specifically mean emotional intelligence, which can curtainly contribute to improving communication skills on the team. I've also found that when hiring someone with mostly expertise outside your current stack it's critical to provide good feedback loops and mentoring early on so they can "get up to speed" and contributing valuable, idiomatic code as fast as possible without feeling as though your entire onboarding experience is trial by fire. This mentoring takes up extra resources and is a net drain on your team in the short term, but pays off in the long term.

>> I hire based on ability/intelligence, not knowledge. Well, yeah that's really your only choice if the experience you need is not easily available. Don't tell me, you are the guy who puts in the not mainstream technology and needs to defend that with justifications such as "when we use (non mainstream technology X) we get super motivated job applicants because anyone with an interest in non mainstream technologies is inherently passionate and interested". That's not a sound hiring strategy.

inopinatus 3y ago
And you are the guy who left Visual Basic, COBOL, Perl, and FORTRAN off their "obviously safe choices for hiring in the future" list, despite them all having once been perceived as such. These inconvenient counterexamples blow up the entire thesis. In practice, the "safe choice" for longevity is only evident in hindsight. If anyone is hiring for TypeScript in 2050 I'll eat my hat
- h0l0cube 3y ago
  I'm in sympathy with your main argument, but given that people still, in 2023, hire for COBOL, a language made in 1959, makes me think you'll be eating your hat.
  - inopinatus 3y ago
    Notwithstanding that I'm effectively forecasting the decline & fall of TypeScript as javascript-flavour-of-the-month, note that I shrewdly also granted myself the better part of three decades to launch an edible headwear startup
    - claytongulick 3y ago
      Most of the perceived value that Typescript brings will probably fade once js gets type annotations [1], though Typescript will always have more advanced syntax and capabilities. There are interesting discussions about Typescript becoming more of a run-time type checker, which would be opt-in and have significant performance penalties, but would give more guarantees of type safety. [1] https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations

calvinmorrison 3y ago

This sounds fun until your entire stack is on Perl in 2023 (which, is fine-ish when your CTO was the perl project lead). But then you have a bajillion dependencies that aren't really updated anymore, you end up owning most of the Mail::Toolkit libraries, etc. and nobody really knows perl that well. I mean, a lot of us can jimmy around in Perl, but of the real Perl Gurus in the world, you will end up hiring 50% just to keep your company going

ttymck 3y ago

I think I'm rather able and intelligent, but there are just so many footguns in golang that my team doesn't have the knowledge to avoid.

drzaiusx11 3y ago
Just curious, what are some of those footguns your team is encountering? Only thing that comes to mind is the somewhat tedious error handling imposed by the language. Which language would you say had _less_ footguns than go? Or was this sarcasm and it went straight over my head?
- ttymck 3y ago
  I guess I am just bad at golang. Loop variable pointer and nil struct is not nil interface are the two that continue to hound us.
  - ttymck 3y ago
    Also: type MyError {} var _ error = (&MyError)(nil) errors.As(err, &MyError{}) --- Panicking because it needs to be &&MyError{} instead is a similar gotcha.

drzaiusx11 3y ago

"Ability" by itself is a bit vague here, but I will say that having a proven trackrecord in their ability to learn is something I specifically look for in a candidate. Not only learning new tech, but also learning from mistakes and experiences over time. However, I don't think raw "intelligence" is the right metric for hiring. Unless you specifically mean emotional intelligence, which can curtainly contribute to improving communication skills on the team. I've also found that when hiring someone with mostly expertise outside your current stack it's critical to provide good feedback loops and mentoring early on so they can "get up to speed" and contributing valuable, idiomatic code as fast as possible without feeling as though your entire onboarding experience is trial by fire. This mentoring takes up extra resources and is a net drain on your team in the short term, but pays off in the long term.