It saddens me to hear such stories as they show up from time to time. I can't help but feel that a lot of programmers just decide to stop learning at some arbitrary point in their career (my observations suggest that point is around the end of their university term or their first job). The industry too seems biased heavily in favor of using lowest-common-denominator, dumbest possible solutions they can get. And not "dumbest" in the sense of "simple therefore robust" - but in the sense of "barely suitable for the job at hand". It's like wanting to dig a pool, and hiring a lot of people with spades, even though you can get excavators for free - but what, you couldn't be bothered to find a few drivers? And the spade crew comes and is all, "no way we're going to learn to operate an excavator, that's too much, let's dig by hand".
I can't explain it any other way. Learning Clojure, or another Lisp, to the point of being comfortable around a codebase, is a matter of weeks for an experienced programmer. It's comparable to the time you need to even figure out how to rewrite an existing mid-sized codebase, and since you have to read it to understand it, why not learn the language along the way? Then suddenly the rewrite isn't needed. But it feels like a concept of learning a new language on the job isn't even considered by people.
> I can't help but feel that a lot of programmers just decide to stop learning at some arbitrary point in their career (my observations suggest that point is around the end of their university term or their first job).
Indeed.
I had the frustrating, but ultimately fortuitous, situation of having my first job be one where I was asked to build a solution with woefully under-powered tools. I'm not even talking about the difference between hand tools and power tools - I was essentially asked to use kid toys.
That situation made me very angry, and I was constantly working overtime to make up for the lack of productivity of my tools - even then we were going to miss our deadline.
Finally, I managed to convince management to let me and my team use real tools - nothing super advanced, but well suited for the job. Very quickly we turned around the release, I started working normal hours, and when I left that job shortly after the release my employer found that they didn't need to hire a replacement because the workload was so much less.
This experience taught me that the power of your tools does matter, and that the initial pain of technology transition can easily be outweighed by the benefits of using something better.
For me, the quality I look for in my tools is: does it reward mastery? I'm not (primarily) looking the initial growth curve and how long it takes before I get to my current productivity. Rather, I'm looking at where the ceiling is.
I can't explain it any other way. Learning Clojure, or another Lisp, to the point of being comfortable around a codebase, is a matter of weeks for an experienced programmer. It's comparable to the time you need to even figure out how to rewrite an existing mid-sized codebase, and since you have to read it to understand it, why not learn the language along the way? Then suddenly the rewrite isn't needed. But it feels like a concept of learning a new language on the job isn't even considered by people.