Comment by 0xB31B1B | Hacker News Reader

Comment by 0xB31B1B | Hacker News Reader

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.

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.

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

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

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.

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?

It takes way longer than 3 months to become an expert in say the JVM.

Rarely/never have to be an expert on day one. A large system will take at least three months to learn anyway. Easy to interleave a platform with that.

A competent developer will be decent at month one, an experienced-pretty-good by month three. An asymptotic gradient, if you will.

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?

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.

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)

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.

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.

The article just talked about $TECHNOLOGY in a general form, it didn’t even limit the discussion to web technologies. Hence my comment.

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.

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

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.

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.

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

Reply on news.ycombinator.com