Comment by tstrimple
1 day ago
Very much this. The concerns with running a six person team are quite a bit different from the concerns of directing hundreds to thousands of developers across multiple projects. No matter how good the team is and how well they are paid and treated, there will be churn. Hiring and supporting folks until they are productive is very expensive and gets more expensive the more complicated and number of different stacks you have to maintain.
If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible. Yeah your super star devs already know most of the languages and can pick up one more in stride no problem. But that's not your average developer. That average dev in very large organizations has worked on one language in one capacity for the last 5-15 years and knows almost nothing else. They aren't reading HN or really anything technology related not directly assigned via certification requirements. It's just a job. They aren't curious about the craft. How are you able to get those folks as productive as possible within your environment while still building institutional resiliency and, when possible, improving things?
That's why the transition from small startup with a couple pizza teams to large organizations with hundreds of developers is so difficult. They are able to actually hire full teams of amazing developers who are curious about the craft. The CTO has likely personally interviewed every single developer. At some point that doesn't become feasible and HR processes become involved. So inevitably the hiring bar will drop. And you'll start getting in more developers who are better about talking through an interview process than jumping between tech stacks fluidly. At some point, you have to transition to a "serious business" with processes and standards and paperwork and all that junk that startup devs hate. Maybe you can afford to have a skunkworks team that can play like startups. But it's just not feasible for the rest of Very Large Organizations. They have to be boring and predictable.
I've seen a grown man nearly start crying when asked to switch programming languages. It would of at most been a few weeks to help with some legacy code.
He starts mouthing off about how much more he can make somewhere else. Management relents and he got his way.
>If you want to have efficient portability of developers between teams you've got to consolidate and simplify your stacks as much as possible.
Amen!
I'm often tasked with creating new frameworks when I come to a new company. I always try to use whatever people are already comfortable with. If we're a NodeJS shop, I'll do it in NodeJS.
Unless you have very unique challenges to solve, you can probably more or less use the same stack across the company.
On a personal level I think it's a good idea to be comfortable with at least 3 languages. I've worked professionally in NodeJS, Python, and C#. While building hobbyist stuff with Dart/Flutter.
I don't have strong opinions either way, but if my boss expected me to learn Rust I'd probably start looking elsewhere. Not that Rust is bad, I just don't think I can do it.