5 ms·
The problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average prog
by tabtab 8y ago
The problem with "choose the best paradigm/computational-model for the job" is that mastering each of the possibilities takes a lot of time for the average programmer. It may be better to master a few than spend so much extra time mastering them all.
I have accused some academics of "promoting ideas that require more education" so as to line their wallet. It didn't go over well and I got counter-accused of "promoting mediocrity" so that "my type" don't have to learn. (I don't believe such bias is intentional, just human nature. We are all biased in ways we don't know just by the fact we only live one life.)
Rather than delve back into that bitter debate, I ask that people consider the economics of it: is it better on a macro-economic scale to spend extra education to master many paradigms/techniques, or to settle on a few to get through school/training faster? (There's always going to be niches that need specialized training/skills.)
The average programming career is relatively short-lived: you either have to move into management, analysis, project planning, etc. or be subject to agism. For good or bad, the industry doesn't "like" old programmers. RSI (wrist problems) is also common with seasoned programmers. Thus, I believe the shorter-education approach is the economically logical one. You are welcome to disagree.
- imh 8y agoPerhaps if most everything an industry uses is learned in college, you're setting that industry up for a low skill cap and thus maybe ageism. Anyways, if someone can get more done by using skills XYZ, maybe they'll outcompete firms not using it, and now we all have to learn XYZ or be relegated to more junior positions ¯\_(ツ)_/¯
- tabtab 8y agoRe: if someone can get more done by using skills XYZ, maybe they'll outcompete firms not using it... Some orgs might be, but they are better off hiding their secret from competitors, and thus we are not likely to hear about it. Warren Buffett often expresses shock that universities and investment organizations ignore his well-published techniques, following BS and fads instead. He and other "value investors" have big bucks lasting decades to prove it; they don't. They only have silver words and catchy-sounding theories. IT is the same, I'm afraid to say. The GREAT LIE of IT is that there's not a lot of real science in "computer science", beyond machine efficiency. It's much easier to do science and math to test and measure machines than it is the human mind, but code is meant for the human mind as much as machines. Humans make, read, and modify software, not machines: computers are just dumb automatons (hopefully) following instructions verbatim.
- crznp 8y agoIn Java, I can assume that other developers took an OO approach, even if that isn't ideal. In Clojure, I can assume that they took a functional approach. In Scala, it is hard to be sure. So, is the increased expressiveness worth the decreased predictability? For one developer, it probably is worth it. For a large team distributed over space and time, it probably isn't, even if everyone is comfortable with each individual paradigm.
- ergothus 8y ago> The average programming career is relatively short-lived: you either have to move into management, analysis, project planning, etc. or be subject to agism. I won't dispute the problems in the industry, but I'm not sure you can really say the career is relatively short-lived. I've been at it for 20 years, and while there are far fewer of my age-peers than there are of younger coders, the number is also far from zero. The "requirement" that you move to a related field doesn't seem nearly as certain as when I was younger (I've avoided all efforts at moving away from coding itself with only minimal effort on my part), and just landed a new job pretty effortlessly. In terms of the topic, I agree that newer coders should tackle a bunch of problems in a few different approaches rather than trying to master them all from the start (I certainly haven't, even as an old fogey), but in terms of troubles I've found lack of free time/energy to do so to be the bigger obstacle rather than no longer being a programmer. Then again, the problem I see most among younger coders is not trying to master everything and failing, it's treating everything as a nail for their single hammer. My anecdotal experience is not data, but it is all I have right now: Do you have a stronger source of information that the "average programming career is relatively short-lived"? I've been at this for 20ish years and currently expect another 20 more, but if that's foolish I'd like to know for (reasonably) certain.
- tabtab 8y agoI've seen several articles over the years which suggest a programming career is shorter than the average career; let alone experiencing agism myself. I can't re-find the prior articles at the moment, but here's an interesting article about average programmer age: https://www.businessinsider.com/silicon-valley-age-programmer-2015-4 https://www.businessinsider.com/silicon-valley-age-programme...
- ergothus 8y agoInteresting. I'm certainly not disputing the agism of the industry, but having fewer prospects is not equal to being forced out and I remain skeptical of the "shorter career" - then again, I believe women are discriminated against in both hiring and opportunities, so I can't think the same of age and expect different outcomes. The StackOverflow survey is likely not a great data source, but it's a data source. Also, one must track for a growing industry - if we have notably more developers now than 20 years ago, of COURSE they will be younger (and drag down the average age). The data has lots of issues, but I'm forced to conclude that....yeah, agism likely reduces the average length of careers in coding.