| I'm a fairly young programmer, but I have almost the opposite perspective. Tools should be chosen because they offer pragmatic benefit for a particular purpose (usually for servicing a desired business outcome). But in the majority of jobs, tools are chosen for reasons of status and affiliation. Even two of the tools you mentioned, Angular and Typescript, are often derided by proponents of newer, trendier tools. There's also an issue between the experience / what a person can accomplish for you vs. insistence on integration with a particular framework. If someone is a COBOL programmer and can demonstrably solve my problem more expediently with COBOL than by slowly plugging into my pre-existing Java system, then I should want them to work in COBOL and I should solve the problem of integrating disparate systems instead of effectively removing the comparative advantage that the COBOL expert brought to the table by forcing them to do things in my Java system for reasons of uniformity and standardization. Obviously this is a simplification. For example, I enjoy programming in Haskell, but it's hard for employers to locate good Haskell programmers and so there is some extra hiring risk if you agree to bring Haskell into your family of tools. That's not trivial, but it is often deeply over stated. And the actual specifics of that kind of risk are rarely analyzed or considered -- as opposed to just rattling off a glib dismissal based solely on the mere fact that a risk, in principle, even exists at all, because dismissing for this reason is probably convenient to someone else's political power play to re-org around Java or something. Many enterprise technology investment decisions are very bad decisions that are made by non-technical people for purposes of nepotism, status signalling, and creating bonus fuel for middle management and executives. The newer and sexier the technology, the better. Or, if new and sexy doesn't work, then buy a brand, like IBM, regardless of whether it actually fits your needs. I find that most programmers are very happy to learn new things and are even motivated to do it and find it pleasant. But most programmers also cannot deal with being forced to learn clearly and unequivocally inferior tools that don't have redeeming engineering trade-off pragmatism to support their adoption -- which is the majority of modern frameworks, new languages, and libraries. You can say "get with the times" but it's just the wrong diagnosis. "Getting with the times" generally means being underpaid and overworked in order to take poorly designed tools and use them to cram square pegs into round holes. Some people call it "gainful employment" and if it doesn't make you feel soul-crushingly miserable, that's great for you. But other people call it "talent wasting graveyard that will cause me to die early from a life of absurdly needless stress" and they seek other careers. I wouldn't judge those COBOL programmers the way you are. They have a comparative advantage with COBOL and know its pragmatic use. If they recognize ways of solving a problem better without dealing with enterprise Java inanity, and their economic preferences imply that it's just not worth it for them to be overworked and underpaid if they are also forced to use an inferior tool, then they are being perfectly rational. You are trying to characterize it as "adapt or die" but the reality is that many modern software shops are just graveyards, so it is "adapt and die" -- at least by refusing to adapt, you might find some more pleasing way to spend your time before you die. (I'd argue the same goes for other trends too -- like the way start-up jobs are becoming cult-like lifestyle communes, and how basic human needs like privacy are required to be sublimated away in awful open-plan surveillance offices. "Adapting" to "tolerate" these things is a bad outcome -- and for many it's a far worse outcome than being unemployed or having a very hard time with job searching). |
@p4wnc6 what are you using Haskell for?