Or in other words... less intelligent people make better leaders.
On a side note, less intelligent people also write more readable code. The principle, Keep it simple stupid, aka kiss is indeed better followed by people who are described by the acronym. So in other words... A simple and stupid person is better at keeping their code and designs simple and stupid than a smart and complicated individual.
Experience and technical maturity do not equate with intelligence.
Abstractions serve one purpose and one purpose only: to reduce cognitive work load. Any abstraction above a primitive implementation only can offer added inefficiencies . Ex: SQL is less efficient than C++ which is less efficient than assembly. A zero abstraction code base is the usually the most efficient implementation and it will be written in assembly.
So from a technical standpoint, we use abstractions only to reduce cognitive workload because other than that abstractions can only offer inn-efficiencies.
Intelligent people do not put in the effort to learn about or implement proper abstractions because they usually deem it unnecessary to abstract what they perceive to be trivial cognitive workloads..
Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.
From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).
If you want to utilize your intelligence to the fullest you abstract away most of the trivial stuff to the point where it pays. You can still go down and inspect or override the abstraction if it's needed. Experience in this case is knowing what to abstract in what manner so it will work for you. Intelligence is the act of keeping everything in a sane state without over-focusing on unimportant stuff.
What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.
KISS is a suggestion, not a rule. It also applies to abstractions, so in one could argue that doing everything in assembly is actually the "simplest" way of programming, like a rough sketch of a scene is simpler than a full-blown oil painting.
As an aside the whole notion of "intelligence" is a bit twisted with experience IMO. The "classical" IQ applies mostly to dumb pattern matching - a skill one can perfect. EQ can be trained by getting out and deliberately practicing human interactions.
>Abstractions have far more roles than reducing cognitive load. You're completely overlooking platform realities, code reuse, usability and other benefits of reduced/managed complexity.
I am not overlooking anything. The traits you bring up in this statement do offer any performance improvements to the system. Therefore the only other possible benefits that these traits offer is that they reduce cognitive overhead.
>From a technical standpoint efficiency of the code is irrelevant if it's bug-ridden due to it's complexity. Code is for humans, not the other way around. We chisel away at lower-level languages if efficiency is required (Ex. C bindings in Python).
Yes. And intelligent people can write more complex code with less abstractions and have less bugs... We agree.
>What I think you're critiquing is the act of adding abstractions when there's no need for one at a given time, just to make something simpler in name of simplicity overlooking it's usability. This can be attributed to the lack of experience.
I am not critiquing anything. I have not said anything about my opinion on where or when to add abstractions. I have only commented on how a very intelligent person would do it. I never said I was intelligent... All I said was more intelligent people tend to write less readable code and this can be attributed to the fact that they have less need for abstractions. So no I am not critiquing about when or where to write abstractions.
>The "classical" IQ applies mostly to dumb pattern matching
IQ tests present questions with patterns that the test taker usually has not seen before. A test taker cannot "dumb pattern match" a pattern he has not seen. Therefore the IQ test cannot be testing for "dumb pattern matching." If the IQ test measures IQ and the IQ test is not measuring for "dumb pattern matching" then by concrete logic IQ must not apply to "dumb pattern matching." QED
IQ must apply to something more. A general intelligence.
The thing is that all humans have a limited working memory (which generally correlates with 'intelligence'). Whether you can juggle 3 objects in your working memory or 30 doesn't matter; eventually you will get to a problem that you can't hold within your working memory. At that point you will need to start using abstractions for both object-structure and functional characteristics. The limit of what you can do with abstraction is way higher than that of your working memory or intelligence.
As a rule it's always better to properly abstract and structure your code, to keep it as simple and well-formed as possible, and to let your tooling deal with any higher-order actions.
As a bonus this allows other people to have an easy time understanding your code, especially when those 'other people' are your future selves.
Logically it can be a sign of either. If the cognitive workloads are on average hard for normal people and you perceive it to be trivial than you are likely intelligent. If the workload is considered to be trivial by most people and you see it as hard than you are likely not intelligent.
>The thing is that all humans have a limited working memory (which generally correlates with 'intelligence'). Whether you can juggle 3 objects in your working memory or 30 doesn't matter; eventually you will get to a problem that you can't hold within your working memory. At that point you will need to start using abstractions for both object-structure and functional characteristics. The limit of what you can do with abstraction is way higher than that of your working memory or intelligence.
I get where you're coming from. Think of it this way. If we organize the complexity of programs into layers such that each layer functions as an abstraction to reduce cognitive overhead, then we can use the number of layers as a quantitative measure of how much abstractions were used on a program.
A very intelligent person would use 3 layers while a less intelligent person would organize the program into 10 layers. There see how it works? Yes complexity is potentially unlimited but the more intelligent person still ends up relying on abstractions less than the unintelligent one.
I don't think we can compare SQL and C++ like that. Not at all.
You mean productivity as in cognitive workloads can be so high in assembly that it's not efficient? I choose to use a narrow definition of assembly because my argument is that the productivity gains given to an intelligent person by abstractions above assembly language are inconsequential. It wouldn't make sense to use a broader definition. You use the word Productivity but we're really talking about the same thing or in other words "the loss of productivity due to cognitive workloads." Thus your argument is circular to mine and therefore ineffective.
My definition of efficiency is true. SQL eventually executes assembly commands thus it is a higher level of abstraction than assembly and thus it can only be equally or less efficient in terms of space and time complexity. Realistically, the assembly code actually executed is most likely not the most efficient way to execute the code.
Less intelligent are also those less capable of realising that they’re overburdening their cognitive capacities with their convoluted code.
More intelligent people are likelier to notice that they’re making things harder for themselves (even if it is within the realm of tolerability) and look for alternative strategies.
I've seen less intelligent people write unnecessary design patterns and abstractions and end up making things harder for themselves. In essence, the heavy reliance the less intelligent programmer has on writing hyper readable and abstract code ends up damaging the app overall.
Regardless of how simple your delivered system ends up being, you still have to understand what problems you're solving and the reasons behind it. This is almost always a product of factors outside of your control.
Let's assume that in the worst case, you're going to be facing a very complex situation. Now you have three possible outcomes here when delivering.
A) Your solution is simple, because you either did not grasp (or were otherwise unaware of) the complexity of the problem, did not acknowledge it, or disregarded the severity of the problem. Or your organization's engineering culture puts pressure on you to cut corners (e.g. "Move Fast and Break Things").
B) Your solution addresses the complexity of the problem, but it was a lot of work to solve and you did not have the time or experience needed to build it in an elegant or optimally maintainable way.
C) Your solution addresses the complexity of the problem, and is built in a reasonably elegant, simple manner.
Which of these did you say correlates with intelligence again?
Edit: There's also a fourth outcome, reserved for the real rockstars out there.
D) Your solution is to not solve the problem at all, because you found a way to avoid your organization/product having to deal with the problem to begin with, or you otherwise re-assessed the assumptions surrounding the problem. The famous post from a few years ago "Why I Strive to be a 0.1x Engineer" comes to mind.
Less intelligent people are better at this because they have no choice but to do this. Less intelligent people do not have the cognitive power to design the full system so they have to resort to relying on the team to do it.
Very intelligent people tend not to do this. They rely on their own intelligence to direct the team and often times just use the team members as grunts to implement there grand designs.
No matter how smart you are, your cognitive powers will always be lower than the cognitive powers of the entire team combined, therefore any attempt to have the team follow your lead rather you following the lead of the team will be worse off.
The science supports this. Teams with leaders that empower team members are statistically more successful than teams that don't. My anecdotal observation is that these types of leaders tend to be the less intelligent types. They empower you and than get out of your way because they really don't have the intelligence to get in your way.
Here are two statistics about humanity that will lend support to my thesis. Your IQ does not correlate with how successful you will be in life, success being measured as how high you climb the corporate ladder and how much money you make as an individual. This is an actual correlation. In direct contradiction to this... the average IQ of a country highly correlates with the economic success of that country. These two statistics say something about the nature of leadership. It says that leaders succeed off the backs of people more intelligent than them.
IQ does correlate with salary but that correlation is weak and a higher IQ brings in only a slightly higher salary. Correlations between IQ and GDPs however are very strong and a small increase in average IQ is correlated with a significant jump in GDP.
My source is the hive mind book, and my original footnote about IQ was incorrect and completely wrong. My original thesis still stands though. Do you have any thoughts about that? The whole IQ and success thing was just a footnote. I shouldn't of added it in, as you are correct in identifying that the footnote was completely wrong. I believe in admitting mistakes and not charging forward with bias so please critique anything you disagree with... I want critiques that address more than the footnote.
This perspective seems based on a premise of "intelligence" being a one-dimensional scale where everybody has an absolute ranking. I think this is generally a problem with the "IQ" concept that we've all agreed on. It seems extremely oversimplified to me, at least if we want intelligence to mean something like "brain capacity".
Humans tend to construct biased logic around themselves to justify their weakness. We lie to ourselves so that we may be happier. In fact, although there is currently a crisis in the veracity of psychology papers, I recall seeing studies showing a positive correlation between how realistic a person was and how depressed he was.
I can tell you that I strive to be as unbiased as possible. I strive to remain unbiased even when it hurts. This is not a trivial skill. I have not seen anyone call themselves stupid even when they clearly are, in fact the way we lie to ourselves is so powerful that even if you are stupid, you wouldn't know it.
That being said I would say I am more intelligent then average. I don't have IQ test scores but I have data that by common sense should correlate. I went to UCLA where the admit rate for engineering 11%. By that fact, I would assume I have above normal intelligence.
I actually believe the opposite to writing unreadable code. In fact I have a bias for readability and extreme abstractions to a fault. I am a huge fan of functional programming. My observations about super intelligent people are of others not of me (note that I only believe I am higher than the average, not someone incredibly smart).
I also believe that I know what it takes to be a good leader, that's why I'm able to identify the traits that make a bad leader and thus come up with this conclusion.
Please stop trying to equate my personal experience with what I am trying to say. I present my views and opinions in a way where I strive to be impersonal. Please judge what I say with the same impassion.
>This perspective seems based on a premise of "intelligence" being a one-dimensional scale where everybody has an absolute ranking. I think this is generally a problem with the "IQ" concept that we've all agreed on. It seems extremely oversimplified to me, at least if we want intelligence to mean something like "brain capacity".
Well clearly when you have opinions about people. In your vicarious opinions you and others often make a judgement that person A is more intelligent then person B. The ranking is based off of that fuzzy general opinion and my thesis is in no way an exact law or proposition. My thesis is just a fuzzy generality that I believe is true.
Steve Jobs was not an intelligent person when compared to Woz. Yet Steve is often referred to as a genius. I don't think Woz could ever come up with the design ethos that Steve Jobs had around products and this is due in great part to Woz's higher level of general intelligence (IQ).
Additionally statistical conclusions are already established. Hardly worth arguing about all together. It is the things that aren't backed by statistical evidence YET, that are more interesting and worth talking about.
Honestly, I detect a thinly veiled personal ire in your response. Perhaps the bias is with you. Perhaps you write clean code and you use it to justify your supposed intelligence. If so, you wouldn't even know it. Such is the nature of bias.
I ask because reading your comment leaves me with the impression that there's some conflation between intelligence & empathy + humility going on.
Right and this is in line with my statements. Less readable code by common sense will not correlate with being more useful in a work environment. Though intelligent people tend to have other benefits that allow them to excel.
>So how are you measuring intelligence to make these sorts of statements?
Anecdotal evidence. I try to be as unbiased as a biased creature can possibly be.
>I ask because reading your comment leaves me with the impression that there's some conflation between intelligence & empathy + humility going on.
I don't know where you get this from. All I am saying is intelligent people write less readable code... or vice versa That's it. I have not commented on any other factors.
Any fool can write words that any other fool can understand. Programmers write words that computers can understand.