I always read "learn" in this context as "be familiar enough with the basic language properties that I can pick the rest up on the job, get things done, and not be too dangerous, or annoying in code review"
and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack.
I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transferable.
What about your tech leads who are looking for top of market salary? By top of market, I mean within your hiring pool not senior staff principal engineer level at a hedge fund
And the other part of “leading the team” is being able to mentor juniors and help them technically.
What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?
What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?
The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.
For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.
Sorry that contradicts the black-and-white world view you're holding.
I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.
You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.
Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.
> Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.
The reason you would is because while I don’t know Android. I do have years of experience designing systems for field service workers where they go out on the field with mobile devices in places where they may or may not have connectivity. But they still need their applications to work and they work in a “semi connected state” [1] and be able to sync and handle conflicts.
Then you need to know whether the feature you’re going to spend man hours on will break App Store rules. Someone needs to know how long the process usually takes, etc. knowing how to write a complex mobile app is not “easy”.
[1] My four experiences with dealing with mobile implementations
1. Windows CE ruggedized devices back when trucks had satellite dishes on them to get a signal and some customers didn’t want the extra expense of early cellular data plans. These were trucks that delivered propane and other field service work to rural areas or they were in basements
2. Railroad car repairmen in a rail yard
3. Doctors in hospitals that often didn’t have great reception. I wrote the backend syncing protocol for the iOS and Android apps. But I knew the design constraints.
4. Home nurses for special needs kids and often the signal wasn’t strong at home or at the school when nurses would go to the school with the students. This was built on top of a third party forms engine. But you could customize it anyway you wanted using web technologies and it had an API where you could save local data and sync it.
There is a persistent attitude that developers are interchangeable, that the tech matters less than the knowledge of how to apply tech to solve problems.
I think that for architecting systems that's probably true, but as technology becomes more specialized and ecosystems become more complex it's harder for individuals to pick up and run with.
Consider if someone has written lots of PHP and jQuery
Now tell them to write a NodeJS server, React Frontend using NextJS.
It's not just "Oh I need to pick up ExpressJS" anymore. It's a whole beast.
Yeah the fundamentals stay the same. REST is still REST, SQL is still SQL, but actually writing lines of code is still a key activity of the job which people familiar with the technology will be better at.
Personally I run into this any time I try and write C#. There's a massive undercurrent of stuff that I feel I don't understand about C# and I bounce off that ecosystem every time I try
And you’re going to hit a brick wall at 100 mph thinking SQL is still SQL once you try to treat a columnar database like Redshift or Snowflake like you would a traditional database.
That would be an expensive lesson to learn on the job. That’s just one example of trying to pattern match based on what you know when you hit a new to you technology.
It’s like the old school operations people who study one course of ACloudGuru, get a certificate, call themselves “consultants” and duplicate an on prem infrastructure and internal process and their poor clients wonder why they are spending twice as much and not moving faster.
I agree with all of this - and the skill that leaders need isn’t demonstrating (intermediates can do this), but coaching - this will help develop the team to be able to solve the issues themselves.
You can’t coach what you don’t know. And the reality of leading an engineering team is that when your team members actually seek your opinion on a problem, you have to know the specific solution to specific details, not general patterns.
But as a leader, if you don't know - then it's an opportunity for you and the team members to learn it together, the real point of which is teaching the team members how to adapt. Half the crap people ask me, I don't know, but I'm happy to find out with them. And maybe next time they'll be able to figure it out on their own.
And while you are fumbling around trying to learn the technology, the market is leaving you behind, you’re burning through resources and you’re not creating business value by either making the company money or saving the company money.
and when I read it that way I agree. Some of the best devs I have hired had no prior experience in the stack.
I'm not hiring for Python or C#, I am hiring a software engineer and the skills I value are all transferable.