Domain knowledge is more important than intelligence almost everywhere.
Domain knowledge is more important than intelligence almost everywhere.
Becoming an effective programmer trains one's strict logical and causal reasoning skills, since we're always building or debugging large and complex systems from simpler components. We see all kinds of crazy emergent behaviours all of the time, and learn to understand how such things can happen. There are few other disciplines that exercise such skills so intensely (probably math and physics).
I would love to see a study on how effective various experts are at making predictions about something outside of their domain knowledge. I suspect computer scientists and physicists would fare better than most.
I'm being facetious here, because I'm on a forum dominated by coders and it's a cheap thrill to troll a little bit. So to restate my opinion with less snark, I don't believe software engineers are any more rational or intelligent than other folks in the tech field. Most of the smartest tech people I've encountered have been product folks, designers, researchers, or engineering managers who don't touch so much code any more.
The reason? All those people acknowledge that all the important problems can only be solved collaboratively. They're also less likely to have come in through the comp sci funnel, and they have a more well rounded set of life experiences. Tunnel vision is exactly the problem being discussed. It's like if you're really good at crossword puzzles and you think that would make you a good English Lit Professor. That's coders thinking that their puzzle solving abilities yield philosophical insights.
All the best software engineers are the ones with an intellectual life beyond coding.
I think "rational" and "intelligent" are imprecise words that have different meanings to different people. I think if we restrict ourselves to the questions like, would a computer scientist or an English Lit professor be able to speak more intelligently about genetics, or psychology, or botany, we have a more well-defined question.
> Tunnel vision is exactly the problem being discussed. It's like if you're really good at crossword puzzles and you think that would make you a good English Lit Professor.
Crossword skills aren't transferrable to English lit, so the analogy fails. Computer science and programming are training in deductive and inductive reasoning, which are general cognitive skills.
It's just self-evident that someone who's experienced and adept at deductive and inductive reasoning would also be adept at solving problems and inferring facts in other domains. They are for sure hampered by a lack of domain knowledge, but my point was that, all else being equal (like their knowledgebase), someone who has this training and experience would simply be more effective at inferring facts about a topic they know little about.
I don't think any point you raised contradicts this argument. Yes, people with more life experience or more varied interests have more knowledge to draw upon from which they can infer tangential facts.
But if said person were also a programmer, they would perform even better at such a challenge. And so, in aggregate, such people would perform better overall at such challenges than other professions.
Edit: there could of course be other mitigating factors that overwhelm this argument, for instance, maybe programmers are less inclined to have varied experiences (hyperfocus on computers, say) and so they just have a smaller knowledgebase from which to argue from, and so they appear less effective at such a challenge. But then not all else is equal.
For starters, is the kind of problem solving that goes into coding trivially applicable to other problem spaces? That's why I used the crossword metaphor. To me, coding often feels like a puzzle where the reward in terms of serotonin boost far outweighs the effort put in. Now, if we're talking about higher order problems like system design, that I agree is the kind of complex reasoning that can be used in other contexts. However, that kind of thinking is far more similar to problem solving in other fields as compared to coding, and thus is not unique.
And in response to your edit, I do feel that programmers are less inclined to have varied experiences because, as I said earlier, the field has been placed on a pedestal due to our current economy. So even if the reasoning that goes into being a good coder was applicable to other kinds of problems in a unique way, engineers are stunted by their own prestige (and by other psychological factors we don't need to go into here).
To make good predictions, you need to make good estimates AND understand what your confidence in your estimate should be.
C'mon; I'm a programmer too, but this is just rank arrogance.
I then have the thought, "Am I doing this in areas where I don't have much experience?".
I can only assume there are some pretty stupid thoughts bouncing around my brain.
Yes, and a technologist, I assure you that they often make very valid points, can often see things tech people miss, and even when they're wrong, they should have the right to discuss. Unless you want to shut them up, what over purpose does such a protestation serve?
>Domain knowledge is more important than intelligence almost everywhere.
Domain knowledge built by stupid people (or by ideology, or for profit, etc) will be stupid domain knowledge, that intelligence can often see right through. Homeopathy also has its "domain knowledge", for example.
As for domain knowledge built by smart people, it can still have its blind spots, if not for anything else, because of professional bias or some accepted wisdom few dare to contest.
There are of course trans-disciplinary efforts done right but those take orders of magnitude more time than your typical VCs or zealous ladder-climbers allow in development timelines.
Software developers have been bailed out from having to confront this situation up to now because those who ask for software tend to ask for extremely simple workflow-helper type stuff rather than domain-expert-amplifier type stuff (see: pretty much every SaaS webapp ever). But the low-hanging fruit are getting pretty sparse by this point in the bubble.
I was a HS English teacher for about ten years before moving into tech, and this reality was a source of frequent frustration with (most/almost all) new ed-tech offerings. There are enough practical constraints on instruction quality that amplification tools would be welcome; however, improving educational quality through improving instrumental performance does not appear to be a notable focus.
FWIW: I believe the low hanging fruit begins with assessment.