It's really true, in my experience. I managed a team in a company that used Spring Boot for services and batch jobs and Python for data and analytics (including ML). My team had its feet in both worlds so I had to hire for that. My experience trying to find programmers who could code and engineer first and not be slaves to the Spring framework was quite terrible in this context.
Another thing of note: the python side of the team could regularly move across and help with bugs or issues in our services and jobs, but the reverse was rarely true. In the 2+ years I had that team there was one person hired for the services side who could do it, and he preferred Go to either Java or Python.
I'm not sure what causes it—and I'm not even sure it's a bad thing, certainly it must not be hurting these folks careers too much, and maybe it's even helping them—but there's a certain path for developers that ends up leaving them helpless outside whatever narrow ecosystem they've grabbed onto. Usually it's Java or some Microsoft thing.
As someone who very much did not develop (as a person/programmer) that way, it seems baffling from the outside, but there's this whole world of programmers who work like that until they retire or are promoted into management. It seems bizarre to me but it must be working for them. Hell, they might even be the majority of all programmers. Bigcos, particularly the non-tech ones that nonetheless employ lots of developers, are full of such people.
Well, I think the difference between them and Silicon Valley programmers is that they don't constantly learn new technologies outside of work. It's just a 40-hour-a-week job.
I try to learn new things, but I don't do much programming outside of work. I could learn Node.js, for instance... but I've got other things I want to do.
Nah, I'm a 40-hour-a-weeker myself, I'm not sure it's strongly correlated with that.
Some folks, you say "do you think you can do [thing you're basically familiar with] in [language and platform you're not]?" and get a "yeah, probably lemme check it out... cool, compiler and language support's installed, see a couple tutorials here, I'll poke around and get something doing [subset of thing you need] then get back to you on timeline" and very likely it works out fine.
Others, you get "uh, I do (Java, .net), I don't... I don't understand what this is, is it a JVM language? Is there a jar for it?" and it's not really worth pushing any harder. And maybe some of them are deflecting because they just can't be bothered (mad respect), but most seem genuinely nervous and out-of-their-element at the mere suggestion of doing anything but their Java or .net thing (usually it's one of those) they're used to.
Though, again, the latter seem to get along just fine, career-wise. It's just a different sort of path, I guess. Seems really weird to me, but there it is.
There has to be some reason that a language that benchmarks like Java is used to build so many heavy-feeling bloated programs that eat way more memory than seems reasonable, even from big "tech first" companies. Either lots of highly-experienced Java programmers aren't using patterns suited to good performance, or the language actually sucks a lot more than benchmarks/theory indicate. I suspect it's mostly the former.
It's been this way ever since I can recall. "Java's so fast you probably can't tell the difference most of the time". Well, OK, but, I can. So something's going on here.
More popular languages get more early developers, so will be naturally predisposed to have objectively bad developers. You'll definitely find more bad Java devs than bad Haskell devs, but you'll also probably find a higher rate of bad devs in Java or PHP than you will Haskell or F# or something.
Totally true, the whole reason half the popular programming languages exist is that their communities are overreacting to the bad/crazy things that happen in the other half of popular programming languages. Java and C++ communities have a lot of bloated ideas, and the languages themselves lend to that.
In my experience: yes, this is true. I’m not going to speculate about why, but I suspect this will eventually happen to Go as well when/if it becomes a more mainstream language.
At my old company, we would do hiring screens by having people send us simple code exercises in whatever language they'd like. Every once in a blue moon, I'd see a good Java sample, but most of them were bloated crap.
FWIW, the JavaScript samples were also pretty bad because it was before async/await, and they'd all get twisted into callback hell waiting for IO.
Yes, hiring for mainstream languages have this cost. It's true whatever the quality of the language and how many good people are available to work on it.
