5 ms·

This isn't true at all. Its obvious for a senior/staff/principal engineer to claim that their skillset is infinitely transferrable to any job role that needs a

This isn't true at all. Its obvious for a senior/staff/principal engineer to claim that their skillset is infinitely transferrable to any job role that needs a staff level skillse, but its simply not true. There are tooling agnostic skills you learn (managing complexity, upleveling team members, how to actually be a technical leader and make improvements that a manager doesn't explicitly tell you to do) and there are tooling specific skills that you need in an organization (EX: dependency management in java, performance issues in certain DBs, the unwritten/not explicit API issues in different cloud platforms). If I am hiring for a staff engineer, I will be trying to get the combination of "tooling agnostic" staff engineering skills AND "tooling specific" staff engineering skills for my job opening because you don't end up paying more for an engineer that has a well matched "tooling specific" skillset, but they will be more productive. The net cost to me as an employer is simply time, I might need to source 3x the candidates to get a good fit, but its worth it.

malux85 5y ago
Exactly, a senior frontend web engineer is not going to transfer to senior compiler engineer, or senior embedded engineer, or senior game-dev, without a substantial ramp up period from lack of domain knowledge.
- hpoe 5y ago
  But now the question isn't specific technologies it's in entire domains. The counterpoint is that if I am proficient in Ruby, and senior level in Node, and work well in Java, I can figure out and be fluent in Python or PHP within a week or so. Sure if you had someone that was working as an aeronautics engineer designing planes for years they probably would require more ramp up before being able to work on ICBMs, but they would do just fine moving from Lockheed to Boeing.
  - malux85 5y ago
    The article just talked about $TECHNOLOGY in a general form, it didn’t even limit the discussion to web technologies. Hence my comment.
  - JAlexoid 5y ago
    But you're failing to recognize that some tech is almost synonymous with a domain. In my experience I've seen very cocksure senior engineers come in with the mindset that "this is just another tech stack, that I can learn in a week"... failing miserably to recognize that said tech stack is exclusively used in a domain that they're not at all comfortable with.
- morelisp 5y ago
  > a senior frontend web engineer is not going to transfer to senior compiler engineer Arguably XHP/React is successful because some senior compiler engineers plied their trade in the front-end world. Or was it senior front-end engineers digging into compiler tech? How about Servo pulling a bunch of game development techniques into the browser development world? There are definitely technical domains you can gain or lack expertise in, but "frontend" vs. "backend" isn't one of them. Those are business contexts, not technical knowledge.
  - quantified 5y ago
    Now we’re getting from “experience” to “creative abilities and acumen”. Not at all easy to spot on most resumes. Also not easy to spot in most hiring processes.
plorkyeran 5y ago
I don't think that it even is in senior developers' self-interest to claim that their skillset is infinite transferable, as it has the very obvious corollary that their skillset is worthless. The whole idea is much more appealing to the business side who wants to pretend that developers are fungible.
- jonas21 5y ago
  Quite the opposite. If skills are infinitely transferrable, then the skill level of a developer is a function of time they have spent in the field. This makes a senior developer extremely valuable because they will always be more qualified for any job than someone more junior than them and there is a limited (and shrinking) number of people who are at their skill level or higher. (to be clear, I don't believe that skills are infinitely transferrable)
mixmastamyk 5y ago
One skill takes a decade to develop, another three months. I know who I’d choose. You’ve substituted one cost, finding a unicorn, in place of training a good dev that is available. The old phrase, “a bird in the hand is worth two in the bush,” comes to mind. Not only does your post sound unaware of the trade-offs but quite confident. A very fixed-mindset.
- JAlexoid 5y ago
  > The old phrase, “a bird in the hand is worth two in the bush,” comes to mind. It's also applicable to training vs paying for experience. (paying for experience being the bird in your hand) It's always a tradeoff, that you have to balance. The idea that you must never require a particular tech is a poor strategy.
- 908B64B197 5y ago
  > One skill takes a decade to develop, another three months. I know who I’d choose. Not only that, but a senior's job is to mentor junior. Having a senior dev familiar with another part of the stack brings a new expertise to any team. Like a compiler engineer realizing that the app team is basically writing a DSL...
  - mixmastamyk 5y ago
    This happened to me once... we were suffering with a broken system for a while. Then it dawned on me that no one on the team understood it was fundamentally a poor-man's broken finite-state-machine.
- djmips 5y ago
  I agree with you but it's never so cut and dried. Some types of work take way more than 3 months to spin up. More like a year. So it's hard to figure where to draw the line. Maybe hire a promising smart junior if you're going to have to train them anyway?
- treis 5y ago
  It takes way longer than 3 months to become an expert in say the JVM.
gopher_space 5y ago
I wonder where the break point is on looking for specialists vs raising them yourself.
bb88 5y ago
I've got mixed feelings on this. If you give a good engineer enough time, he/she can figure out anything -- but there's a shortage of good engineers in the world these days -- and often a shortage of time. We once had a senior guy that claimed he was "devops" and worked with redhat, but didn't understand the bash shell, nor what "export" meant. It would be one thing if he said he didn't know unix/linux and was learning because he had been working in windows all of his life, but he was as fraudulent as they come. It would have been fine had he been acknowledging this, and seeking me, or others out for help, but instead he started sending his PR's to junior people for approval, who just simply assumed his code worked. It worked great until a prod deployment failed, and I was the one who had to spend a late Friday night figuring out why it failed. Turns out if the guy had just run the script, he would have seen it fail instantly.
redhale 5y ago
Great. Now you've hired someone who already knows everything about all the languages / tools / platforms you're using, and won't "need" to learn anything new. How long do you think it'll be before they get bored and leave?

malux85 5y ago

Exactly, a senior frontend web engineer is not going to transfer to senior compiler engineer, or senior embedded engineer, or senior game-dev, without a substantial ramp up period from lack of domain knowledge.

hpoe 5y ago
But now the question isn't specific technologies it's in entire domains. The counterpoint is that if I am proficient in Ruby, and senior level in Node, and work well in Java, I can figure out and be fluent in Python or PHP within a week or so. Sure if you had someone that was working as an aeronautics engineer designing planes for years they probably would require more ramp up before being able to work on ICBMs, but they would do just fine moving from Lockheed to Boeing.
- malux85 5y ago
  The article just talked about $TECHNOLOGY in a general form, it didn’t even limit the discussion to web technologies. Hence my comment.
- JAlexoid 5y ago
  But you're failing to recognize that some tech is almost synonymous with a domain. In my experience I've seen very cocksure senior engineers come in with the mindset that "this is just another tech stack, that I can learn in a week"... failing miserably to recognize that said tech stack is exclusively used in a domain that they're not at all comfortable with.
morelisp 5y ago
> a senior frontend web engineer is not going to transfer to senior compiler engineer Arguably XHP/React is successful because some senior compiler engineers plied their trade in the front-end world. Or was it senior front-end engineers digging into compiler tech? How about Servo pulling a bunch of game development techniques into the browser development world? There are definitely technical domains you can gain or lack expertise in, but "frontend" vs. "backend" isn't one of them. Those are business contexts, not technical knowledge.
- quantified 5y ago
  Now we’re getting from “experience” to “creative abilities and acumen”. Not at all easy to spot on most resumes. Also not easy to spot in most hiring processes.

plorkyeran 5y ago

I don't think that it even is in senior developers' self-interest to claim that their skillset is infinite transferable, as it has the very obvious corollary that their skillset is worthless. The whole idea is much more appealing to the business side who wants to pretend that developers are fungible.

jonas21 5y ago
Quite the opposite. If skills are infinitely transferrable, then the skill level of a developer is a function of time they have spent in the field. This makes a senior developer extremely valuable because they will always be more qualified for any job than someone more junior than them and there is a limited (and shrinking) number of people who are at their skill level or higher. (to be clear, I don't believe that skills are infinitely transferrable)

mixmastamyk 5y ago

One skill takes a decade to develop, another three months. I know who I’d choose. You’ve substituted one cost, finding a unicorn, in place of training a good dev that is available. The old phrase, “a bird in the hand is worth two in the bush,” comes to mind. Not only does your post sound unaware of the trade-offs but quite confident. A very fixed-mindset.

JAlexoid 5y ago
> The old phrase, “a bird in the hand is worth two in the bush,” comes to mind. It's also applicable to training vs paying for experience. (paying for experience being the bird in your hand) It's always a tradeoff, that you have to balance. The idea that you must never require a particular tech is a poor strategy.
908B64B197 5y ago
> One skill takes a decade to develop, another three months. I know who I’d choose. Not only that, but a senior's job is to mentor junior. Having a senior dev familiar with another part of the stack brings a new expertise to any team. Like a compiler engineer realizing that the app team is basically writing a DSL...
- mixmastamyk 5y ago
  This happened to me once... we were suffering with a broken system for a while. Then it dawned on me that no one on the team understood it was fundamentally a poor-man's broken finite-state-machine.
djmips 5y ago
I agree with you but it's never so cut and dried. Some types of work take way more than 3 months to spin up. More like a year. So it's hard to figure where to draw the line. Maybe hire a promising smart junior if you're going to have to train them anyway?
treis 5y ago
It takes way longer than 3 months to become an expert in say the JVM.

gopher_space 5y ago

I wonder where the break point is on looking for specialists vs raising them yourself.

bb88 5y ago

I've got mixed feelings on this. If you give a good engineer enough time, he/she can figure out anything -- but there's a shortage of good engineers in the world these days -- and often a shortage of time. We once had a senior guy that claimed he was "devops" and worked with redhat, but didn't understand the bash shell, nor what "export" meant. It would be one thing if he said he didn't know unix/linux and was learning because he had been working in windows all of his life, but he was as fraudulent as they come. It would have been fine had he been acknowledging this, and seeking me, or others out for help, but instead he started sending his PR's to junior people for approval, who just simply assumed his code worked. It worked great until a prod deployment failed, and I was the one who had to spend a late Friday night figuring out why it failed. Turns out if the guy had just run the script, he would have seen it fail instantly.

redhale 5y ago

Great. Now you've hired someone who already knows everything about all the languages / tools / platforms you're using, and won't "need" to learn anything new. How long do you think it'll be before they get bored and leave?