The stack an engineer has experience with can be one indicator of the areas they excel in.
Almost all of these concepts could easily be learned in a few weeks by a talented engineer with strong fundamentals in software design and computer science.
Polyfills aren't exactly quantum mechanics. They're not some radically different mental paradigm that takes years to develop fluidity. If you already have a sound basis in the major software engineering concepts, learning polyfills is just a matter of reading the docs to learn the details.
Let's not forget that Jordan Walke was working on back-end infrastructure code just prior to inventing ReactJS. Miso Hevery was working on Java testing frameworks just before inventing AngularJS. So it's not like there's a history of front-end being such a unique problem domain, that it's impossible for outsiders to pick up.
The only major sub-domain of software that I think this may potentially be true of is embedded systems. And even then, that's a big maybe.
But front-end development of complex applications isn't done in a vacuum by one person. It's done by multiple teams, possibly distributed across different physical locations.
As an architect, what is your polyfill story? Does each team ship ES Modules that are later compiled by Webpack? Is each team responsible for loading their own? It's probably more efficient to handle it globally --knowing what all teams need at once as part of a build step-- to prevent duplicative loading of the same polyfill by 5 different teams.
It gets nuanced quick. Nobody can master all these concepts --and reasonable ways of managing them in distributed team environments-- in a few weeks.
And if you think JavaScript is "simple", I encourage reading "You Don't Know JS". What does "this" mean, in JavaScript? I could ask a handful of questions from the multitude of sections in this book, and people writing JavaScript for years wouldn't be able to answer all of them. React and Angular are such a thin slice of the overall problem. Even simple projects will require a dozen or so more NPM packages until you have something remotely useful.
I think this might prove my point. There's tons of great Javascript engineers out there, who are consistently delivering business value, who actually aren't even that knowleadgable about all the details inside Javascript.
Most of the variance in quality between software engineers has to do with technology-agnostic skills rather than stack-specific knowledge. They architect well-designed, modular systems. They communicate with stakeholders. They write robust, readable, testable code. Their documentation is understandable and comprehensive. They're thoughtful about naming things. They can large codebases and keep complexity contained. They understand performance tradeoffs, and anticipate bottlenecks before they occur.
Very little of that has to do with stack-specific knowledge. A developer who does all of the above, but doesn't know all the ins-and-outs of the JS coercion model, is going to be much more productive on almost all practical business problems.
The most important skill usually isn't knowing every single detail of your underlying ecosystem. It's knowing enough about its overarching landscape to be aware of the things you don't know. As long as you know how to ask the right questions and where the limits of your knowledge lies.
Individually yes, but all of these things would take more than a few weeks - possibly months. With onboarding on an average software project also taking months, you could be looking at paying for a lot of unproductive time if you don't hire somebody with some prior knowledge.
The idea of language fungibility is a joke. Sure, it takes you a day to learn the basics of syntax in another language. Learning the whole ecosystem takes considerably longer.
So, let's say that is the case. The lesson is that hiring is expensive and risky, even if you find a candidate whose experience exactly matches your stack. Like you mention, just onboarding for the internal technology and project itself takes months.
You're already sinking a big investment into a new hire. So most times you should choose the best engineer even if it means additional O(project onboarding) time. From a business standpoint a great engineer who takes 6 months to get up to speed is a much better investment than a mediocre one who takes 3 months. Not always (maybe you're an ultra-high growth startup who needs bodies on the floor ASAP). But usually.
And the reality is that dropping stack requirements drastically improves the candidate pool. For one you have way way more candidates to select from. Two, most times when a company is hiring for [tech X] it usually means that the market for engineers who know [tech X] is super-tight. It's just the nature of the business cycle. If [X] is in demand at your company, it's probably in-demand everywhere, and therefore in short supply.
All of which means that if you insist on [X] experience, most of the time you're scraping the bottom of the labor market barrel and getting mediocre engineers. If you're willing to hire from anywhere, then usually there's some sub-sector that's in a downturn. That's a huge opportunity to poach talented engineers, who are being mostly overlooked because their stack experience doesn't align with the hot growth sectors.
There's definitely a sweet spot in terms of stack specificity. There's very little issue hiring a flask developer if you need somebody to work on django. However, if you're a ruby shop and you hire a java developer - even if they are great - you've potentially doubled or tripled your onboarding time.
>All of which means that if you insist on [X] experience, most of the time you're scraping the bottom of the labor market barrel and getting mediocre engineers.
I don't think that's necessarily true. Nonetheless, this could be market specific. I can imagine that hiring a developer in, say, Ohio might make your approach more worthwhile compared to hiring in SF, where the talent pool is deeper.
The GP's calculation had a very important weakness that it does not take retention under account.
The sweet spot will be mostly determined by retention. And the very bad places that have impossibly (sometimes literally) specific requirements are probably correct on requiring a narrow set of competences. But of course, they would gain more by improving themselves so the developers don't quit as often.
You think? I went the other direction and I don't think it was so hard. The language was the easy part of onboarding, the hard part was all the company specific stuff.
I don't think that's true at all. I've met tons of Java devs who moved to Ruby with minimal pain. It's still OO and many of the same patterns apply.
How about average engineers with average fundamentals? The kind most people will on average be hiring and working with.
The big problem with embedded is that when things go wrong, it has a cross cut with electrical engineering--you have to understand datasheets, read a scope, and understand that digital signals sometimes aren't.
I have never known a good embedded software person who is software-only. Even DSP-types with EE degrees don't often operate on hardware very well.
Generally, the best embedded software types are good hardware EE's and passable software people.
I consider myself a very good embedded engineer, but my software is merely "straightforward". Of course, the best software people I know claim I should take that as a compliment, and they are all happy to work with my code.
I don't take lightly your skillset at all, but it comes a time when people start using inneficient solutions because it's faster to produce, and you have plenty of hw resources, so... why not? Do it in Python and improve it later... maybe, and then you don't. :-)
I believe you get my point. Not that I personally think using micropython is a worthy path solution for embedded dev as of now, in a professional context. But there will come a time when that can make sense, as it's already the case in the RPi, as I mentioned.
> I consider myself a very good embedded engineer, but my software is merely "straightforward"
And that's where I make my business. I'm merely a straightforward embedded engineer but focus on the software/hw integration making the excellent work of people like you work with the external world, databases, desktop/web UIs and all of that using software engineering practices. Basically doing the "cloud", "edge" and "IoT" buzzwords.
An average company, paying average wages, solving average problems is better off getting an average developer specialized in the area they need.
The most important 67-80% of front-end work can probably be learned in a few weeks by an experienced engineer who already has a high level understanding of the web. The last 20-33% hides some things that are trickier to wrap your head around, along with more than a few WTFs, and a never-ending stream of subtle cross-browser differences.
It may still be plausible that a talented engineer with strong fundamentals in software design and cs could cover the ground quickly. But the message of the "don't call yourself a programmer" piece might be understood as being as much about how you're going to spend your time as it is how you're classified professionally (though those are certainly related): are you a stack-whisperer, or are you a badass problem solver with expertise in translating a problem domain into a formal-ish system which enables expands the capabilities of the human system (and networks of machines) it's embedded in?
My bet as someone who did years of front-end focus is that for all but the truest 10xers, if you focus on front-end and try to be thorough, your risk of being a stack-whisperer jumps dramatically because of how much of your time corner-case ephemeral arcana will chew up. Front-end is certainly not the only place in the industry where we've let that hazard run away with the lives and time of too many talented people, but it's a popular one.
It's web development, and let's face it, many companies don't want long term talent, they just want someone to finish their current project and move on. Which can make sense in some circumstances. You don't need a software engineer level guy to make a dashboard.
People that are beyond the framework user level end up also moving on from even considering working on those kind of jobs.
Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”
It really depends upon the exact situation. We can all make up bullshit examples to make either option look stupid.
This is the “secondary employment” market where HR policies aren’t optimized for in demand fields like software development. The immediate managers are usually helpless to do anything about it and see employees they spend time training leave for greener pastures. Being that is the reality, what other course is there but to find people you don’t have to train?