My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program".
I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form.
Even the smartest person on this planet still needs time to learn things.
Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way.
And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack.
I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.
Read documentation and implement.
If you're telling me that anyone can be as good as someone else who is equally smart but with 2-3 years of experience with that specific tech stack, I'd say that can't be true, almost by definition.
More efficient than a jr with 1-2 experience in it for example. ( If the implementer that is new knows multiple languages and there isn't a fundamental big difference ( eg. the new language is functional))
Personally I've never had problem doing project in new languages and had never have client making a point out of it. They just look at the references and products I've completed personally or as the lead. But those clients are business with real needs and problems to solve. Not architecture astronauts who would go to holy wars over things that do not matter much in real world.
On one side you pit a "real senior programmer /architect with years of active product design and development under the belt" and on the other side "person who learned to screw size 8 bolt into size 8 nut and been doing this and nothing else for years".
My point is that for this situation:
* person A (truly senior polyglot developer just now starting to use a specific stack)
* person B (truly senior developer with experience primarily in that specific stack, all other things being equal)
Person B will smoke person A at the start of the project, since they're already ramped up. Person A will have to learn, that's why we call it "ramping up".
But to your point. Yes, experience is critical for mastering a skill.
It's a new language. Syntax, semantics, common patterns, high level approaches to things (you could call this culture).
It's a new VM (possibly) or compiler.
It's a myriad of libraries.
It's operational tools around the main tech stack (debugger, tracing/performance tools, deployment tools, logging tools/frameworks, etc).
To truly master a mature software stack takes years. Yes, a smart and experienced dev can hack their way around with the help of an experienced team, but the real test will be when the same dev looks at their own code from the start.
Though even that's not a sure thing, because if it's one thing developers have plenty of, it's hubris. Sometimes it helps, but many times it doesn't.
> I also don't think the claim was that our candidate would perform at the level of a senior dev.
No, the claim was even funnier, that the candidate will be a competent developer because he has a PhD in physics (a field somewhat related to software engineering, if you squint really hard, but not really).
But more importantly, you also don't need to very much about the above if your goal is just to reach competency. My understanding is the OP was claiming the candidate will be competent because "he knows how to program". Now that may mean anything from "candidate has written a python script to display a graph once" to "candidate is the lead dev of our game engine".
If the former, then of course, yes, they would likely struggle a little bit at first (though I would expect competency within hours -- many frameworks, as part of their core design, aim to reduce time-to-competency). If the latter, give them a brief overview of the system architecture, point them at the docs, hand them a ticket, pat them on the back and walk away.
I don't doubt that they guy you work with is excellent and is able to seamlessly make this switch, but I have previously worked with someone who was excellent at C++, and had a PhD in something maths related (can't remember what exactly), and completely failed to get anywhere with JavaScript. As in: took 2 weeks to write a script that would take me a couple of hours, and it was still in a pretty bad state at that point.
It seems that they hadn't encountered async programming before and really struggled to get their head around it. The silly thing is their program didn't actually require any concurrency so they could just have stuck an `await` on each async function call and treated it like synchronous code, but they were convinced that async-await was too complicated to learn up front so they had a complete mess tracking everything with callbacks.
Actually, I think some of those might be Pokemon.
[EDIT] I had in mind Android, Yarn, and AWS Lambda + Java (as of a couple years ago, anyway), in order, for those examples, for the curious :-)
> New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong.
They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. My point was merely that while some people will easily transfer their skills to different languages and domains, this won't be true of everyone.
That tends to make it harder. I've experienced quite a few people more "senior" than me (either age-wise or company-tenure-wise or both) who had trouble having the less-senior guy telling them things like suggesting different designs or code refactors. Some things were just not obvious why my suggestions were better, but they were based on experience with this particular technology. So they preferred to ignore the advice and run into the issues I and other colleagues had run into 3 years prior cause they didn't want to listen. Sadly, they didn't always have to live with the consequences since some of them moved on before the consequences became obvious, so we had to clean up the mess we were suggesting against in the first place.
Seems totally normal. And most likely, after a few weeks this person would get the concept.
Reminds me of stochastics in school, which was a subject that wasn't immediately natural for some who were otherwise very good at math in general.
For me it's bit fiddling for example: I bought Hacker's Delight some months ago and first had to really work through even the most basic things on paper until it stopped to feel like magical hieroglyphs.
That’s seems an off-axis question to me. “These devs are expensive and a constraint on our growth. I want to hear more tappy-tappy…”
What’s the alternative if you have a good backend programmer and an excess of front-end work at the moment? Have the backend plow further ahead? Move items that “belong” in the front-end to the backend just for dev capacity reasons? Decide your architecture based on which devs are free in a given sprint?
That backend dev might be 50% as efficient and still result in more total value delivered.
[1]: https://world.hey.com/dhh/the-one-person-framework-711e6318
His tasks are currently backend-ish(still TypeScript though). I wouldn't throw anyone into the deep waters of frontend unprepared.