The Programming Talent Myth (2015)
lwn.net
lwn.net
This may be true if your definition of programming is the literal act of writing code / recalling syntax, and learning new tools. Of course, that's not really what programming is. That's the easy part.
Programming is about problem solving, code is simply the tool. Critical thinking/problem solving ability, the ability to think in abstractions, the ability to hold a large amount of information in your head all at once, etc. are all skills, and not skills that the majority of people are particularly good at.
We wouldn't judge a carpenter on e.g. his/her ability to use a saw, or a EE on their ability to use a scope. I never understood why so many put so much emphasis on the tools a software dev knows.
Of course we do, but no one is saying only the best should be hired and the rest should go dig a ditch. Most programming tasks do not require top level talent to accomplish, but when I'm hiring I'm going after the best candidate I can get, and that has little to do with e.g. what web framework they are most familiar with.
That's actually the whole point of scientific training: teaching people to use the tools of science, including thinking logically and avoiding sources of bias and so on.
If you want to go back into antiquity, the ancient Greeks who started the whole Logic thing, Socrates, Plato, Aristotle et al, they never presented logic as some kind of innate ability of human beings, rather they set out to teach it as an instrument of thought that was far from innate. Because if it was innate, it wouldn't need all that work they put into it.
That said, we build concrete skills around how to make the best use of those abilities. We build memory skills to be able to quickly bring things out of short term memory back in. We build abstractions and concepts that allow us to efficiently analyze complex situations. We learn to think better with the capacity that we have. However our capacity doesn't seem to be readily changed.
As a concrete anecdotal example, several who have taught CS for decades tell me that most students simply can't "get" pointer arithmetic or recursion. Their brains don't go that way no matter how much they try. People who do master it learn those things fairly quickly and then can move on. The specific abstractions can be taught, the ability to think through those types of abstractions seems innate.
None of this minimizes the effort needed to become a good programmer even if we have the capacity. However the fact that most humans can't become programmers is why there is a job that typically pays 6 figures where many who are successful in it are self-taught with no more than a high school degree or GED.
Or maybe they're just bad teachers.
Luckily, since I really wanted to learn, I had to seek alternate resources. I was fortunate to stumble on Stanford's Cs106a taught by Mehran Sahami and it changed my life forever. That man is the gold standard for what a teacher should be. He broke down complex ideas and made them look so simple.
Since then, I use a combination of different resources to learn said "difficult concepts". Recursion, got it...pointers, got it too. I have used Standford courses, Berkeley course, udemy, Udacity, Coursera and even youtube to learn. These sites have some really good teachers.
I have since come to understand that CS is really not that difficult. All is takes is a willingness to learn and a good resource to learn from.
Maybe so, maybe not. However I never had trouble when they tried to teach me things. And have heard good things from others who they taught.
One of the people who expressed this basic opinion to me is https://www.amazon.com/Randal-Schwartz/e/B000APA744. He is also someone whose expository abilities are widely recognized as being excellent. And he is also an example of a self-taught programmer with no degrees beyond graduating from high school.
The above is a slight simplification, but I think it's a fair summary of the current consensus among intelligence researchers, given the word count.
The upshot was that genetics is probably more of an upper limit on IQ, and that for children raised in poor conditions, environment plays a much bigger role than genetics.
Plenty, of smart, dedicated people have been trying for decades to devise interventions to permanently boost IQ among children raised in poor (for the first world) conditions, and unfortunately not much has turned up. Instead, there is a familiar pattern of small pilot studies that show initial promise, but whose gains tend to wash out when the program scales up to a less than one-to-one child/child psychologist ratio, or even when the children are followed up on in adulthood.
The gains from permanently boosting IQ among low-IQ children would be so great that it might still be worth banging our heads against that wall on the off chance that we find something that might work. But we should keep in mind the base success rate of past interventions.
And isn't it the most amazing coincidence that those who are thus exceptionally gifted are uniquely placed to benefit from the demand for those very abilities in an extravagantly lucrative profession?
I mean, imagine what would happen if everyone could program! Where would those six-figure salaries go then?
I mean, imagine what would happen if everyone could program! Where would those six-figure salaries go then?
That was the exact point that I was making.
There is no coincidence. It is economics 101. In a free market, the salary is set by the laws of supply and demand. If people who can program are in short supply and create lots of value, the supply/demand curves will meet at a high price point. That is good for programmers. If everyone could program, then the price point would be lower and programmers couldn't collect those salaries. Programming has low explicit barriers to entry AND high salaries. This could not continue without implicit barriers to entry of some sort.
How low are the explicit barriers? I personally know several programmers who were homeless teenagers, later received GED degrees, and are self-taught in programming. These are mostly highly paid professionals. (One that I know decided as an adult to go back and pursue university now that she could. She's only 30 - by the time she's my age I'm confident that she'll also be a highly paid professional.)
Let's continue with economics 101. When you move a person from a non-programming job to a programming job that pays more, it is obviously good for that person. It is also good for society as a whole - that person is doing something more productive. It isn't so good for other programmers, though, because it reduces their salary.
Speaking personally, I grew up in poverty. My life is much better than I feel I deserve, or than I need. I also like seeing the lives of others around me improve.
Therefore I have encouraged many to take up programming, and spent untold volunteer hours answering questions from people who want to become better programmers. I have zero interest in limiting who gets to program.
For a political example I completely oppose H1B programs in their current form. I think that we should allow free immigration for competent people AND once they arrive we shouldn't restrict them from finding the best job that they can. The current quota system which provides incentives for companies to swear up and down that they are paying a competitive wage, while in fact they are paying under the market price, and then trap the people that they import in jobs that don't make full use of their talents.
How far down the rabbithole does this go?
I have never programmed iOS, but I'm completely positive I could program for iOS.
10 years of occasional programming, from python, to school projects, to database development, to android apps, to full stack react-native development.
I'm confident that I can build an iOS app.
Programming and understanding how computers handle inputs are tools. But programming is more mindset than anything. The only benefits of knowing the specific language or framework would be skipping the 1 month of learning syntax.
I'm a recreational programmer mostly, but at some point, you realize you can do full-stack and you realize that everything is possible with google and stack overflow.
Ex teacher here:
Some people really really seems to have a harder time with certain subjects than others.
I took pride in being a good teacher but I have experienced one person who - despite being normal and being able to keep a normal job - just couldn't grasp the basics of computers.
And by basics I mean:
Connect power cable, press power button, wait for Windows to load, type password and open Internet explorer.
It would stop somewhere in between there each time.
There is nothing wrong with that just like there is nothing wrong with me never being able to become a long haul truck driver (falls asleep), pilot (partially colour blind), or soccer star (hopeless).
> but it's the enjoyment I derive from these things that I believe is the difference between some people and I.
Thus is huge as well. Possibly also underappreciated.
When you are slightly better or faster or just find doing it (whatever "it" is) more rewarding compared to your peers, then it takes lower effort to get the same reward. This means you are more likely to spend more time doing it. This means that after a while you have more practice than your peers, so the difference in ability is amplified. Now various grownups around you notice and complement you on it, get you lessons to do it better, provide you with supplies, &c. and the difference grows.
By the time you are looking at teenagers, it's hard to tell how much of the difference stems from natural ability, and how much of it is this snowball effect.
Programming is a form of expression for me, and I derive great satisfaction from solving and creating software which truly helps the users I work for. On the the other hand my lack of detachment from 'myself' and 'my work' also can cause some unnecessary pain at times, but it's a work in progress.
If anyone has achieved the balance I seek, I'd be glad to hear their story!
Right. Can (or should) appreciation and enjoyment of a particular kind of work be taught? Or is it an innate quality... a talent, even?
It's the same for a lot of jobs. Intellectually I can do what pure business people or lawyers but I don't find it interesting so I don't have passion for it and will never do well.
On the other hand the first time I saw programming stuff I got excited immediately and had passion for it. I think that's my real talent.
Ones ability to program is directly related to ones tenacity to practice programming.
When I was an athlete in high school and college there were people who barely trained and ate whatever they wanted and were far better than people who worked their ass off and counted every calorie.
Programming is much the same. I've had lots of people want me to help them learn, some people are naturals and will make more progress in a few days than most people do in weeks or months.
I'm not sure why people get so defensive about it, nobody cares if you say someone short can't make it in the NBA, but say it about programming or some other mental endeavor people get upset.
We absolutely should because it's a fundamental aspect of doing their job. The difference between me and a professional carpenter is literally the ability to use tools effectively to build an item. I know whether to use a dovetail or dowel joint as well as any professional, but I guarantee the pro will achieve a better finish in much less time.
It's like theoretical CS vs. real-world programming. It's good to know sorting strategies and whatnot, but knowing how to use the tools is what gets stuff done.
The problem is that we don't pay engineers to crank out pre-designed classes in a specified language with a specific editor. We do pay day laborers to go dig a certain trench over there with these particular shovels and picks.
Software engineering is so much more open-ended. We're paying people to "go help the team make the yard more water efficient".
In other words, if we had more well-defined roles for "coder" versus "engineer" versus "architect", it might make sense to test on the ability to use tools, but in general people in this thread aren't making that kind of distinction because the tech culture in general doesn't make a clear distinction. Otherwise, we'd have "coder" job interviews that didn't include algorithms or open-ended problem solving questions.
A rather trivially learned part of their job. It has little bearing on their ability to build a beautiful cabinet.
>The difference between me and a professional carpenter is literally the ability to use tools effectively to build an item
It's much more than that. How about Michelangelo? Do you think the only difference between you and him is that he's had more practice with a chisel? Doubtful.
>It's like theoretical CS vs. real-world programming. It's good to know sorting strategies and whatnot, but knowing how to use the tools is what gets stuff done.
This is the lone of thinking that leads hiring managers to build teams of mediocre devs with a lot of buzzwords in their CV. I don't care so much that you know e.g. C#, I care that you are a great problem solver. If you have that part down I'm fine with investing a little time into you so that you can learn C#, ASP.NET, whatever. The latter bit is easy.
That's not to say problem solving is not extremely important, but the time suck created by bad tool use (or not using tools out of ignorance of their existence) ultimately reduces the productivity of a programmer, or in some cases, whole teams.
Agreed. There's definitely a balance point there - I remember when I got to the point that I not only recognized that this a bad idea, but where they actively started bothering me even for one-off scripts. Something as simple as setting them as constants at the top of the script makes that feeling mostly go away and requires almost no extra effort when implementing.
There are many times when I think "This is really brittle. Surely there's a better way to do it...", which is usually quickly followed by "I'll figure out that better way later, for now, just isolate it and make a note to fix it when this is done."
What? Yes we absolutely would.
The metaphor is ridiculous.
Now the amount of knowledge required to do even mundane tasks is an order of magnitude more. No one can memorize all the APIs and frameworks needed to do their jobs programming. I couldn't work without search. I don't memorize anything anymore. I work on dozens of different technologies.
Basically, I've become a mediocre programmer at a large number of different programming tasks where once I was expert at a very few. I'm the same person but the meaning of what is a programmer has changed over time. I'm OK with that.
It's hard not to conclude that this is one axis in the multi-dimensional "ability" space.
Between a guy who needs to spend 5minutes googling for a class/module/function and someone who prompltly writes it down, there is no question who is a more capable programmer.
If I were to measure a programmer's ability, I.e., what makes a "good programmer", perhaps in the context of am interview, I would therefore not test rote knowledge.
that was the reality of programming before the internet
Why did you have to memorize everything? I have also done x86 assembly. You remember what you can. You look up the rest. Same today.
It's like the difference between being a stammering tourist in a foreign country who is constantly flipping through a dictionary to make elementary utterances, and a native speaker.
I first realized this many years ago after writing an emulator for the Motorola MC68010. Unrelated to that project, I had the occasion to write some assembly code in the same instruction set. Just, wow ...! It was like, I .. know ... everything ! (cue sound of thunder, lightning effect.)
Edit: For example, for a different project I knew the hex codes for every 8051 instruction. This was necessary to be successful debugging using a logic analyzer. Looking up each op-code would be prohibitively slow.
We really aren't as different from computers as we sometimes like to believe.
1. context switches are much more expensive than looking at a keyboard to find the key to press,
2. memorization enables you have a more complete mental model which greatly speeds up design, reduces bugs and enables you to find bugs faster.
3. you gain surprising insights if you can run the program in your head when you are falling asleep, in the shower or walking around.
When I am doing cryptanalysis the first thing I do is commit the protocol to memory. Sadly if I'm not working on it 24-7 I quickly forget and have to rememorize.
Looking stuff up took a lot longer then. It's the difference between firing up a search engine and typing words versus getting in your car, driving to the library, finding parking, walking to the door, finding the card catalog, finding the right card in the catalog, finding the right stack, finding the book on the shelf, scanning the book index, then finding the right page in the book. Memorizing had a better payoff back then.
Or think of it another way: looking stuff up today is like accessing L2 memory, and back then it was like a cache miss, where you had to take a trip out to disk before you could continue useful work.
(#1) "talent" doesn't exist: knowledge and skills can be learned. No infant comes out of the womb knowing 5 languages or physics equations or the syntax of "printf("hello world")". Every single human who knows how to do something well at one point in their life did not know how to do it well. If one can improve by learning, it means talent doesn't exist. This aligns with Carol Dweck's "growth mindset", the 10000 hours meme, self-improvement, etc. This internal perspective compares oneself at time_before vs time_after.
(#2) "talent" is a subjective ranking of people's abilities: there are people who are noticeably better at expressing their skills. E.g. NBA basketball player Shaq O'Neal has spent more than 10,000 hours practicing free throws with a dozen different coaches to achieve 52% success, but there's a high school kid that can sink them at 80%. We can say the kid is "more talented" at free throws. To say that "free throws" is a "learnable skill" doesn't change anything about noticing the obvious difference in abilities. If Person A learns faster than Person B, that in itself is a talent. This external perspective compares people against other people.
People who hold meaning #1 vs people thinking of meaning #2 are having 2 different conversations. E.g. when companies say "they are looking to hire the most talented" (meaning #2), they are not talking about people who can self-improve (meaning #1).
In this essay, Jacob Kaplan-Moss is talking about meaning #1. Yes, you can read it and take all his advice to heart. However, you still have to understand meaning #2 to properly decode what others are talking about when sports teams, music record labels, Hollywood, venture capitalists, and startups all say they are "looking for the best talent".
You may be hiring for guitarist and require at least 3 years experience playing the guitar. J.S. Bach applies, but has never played the guitar. As an industry, we typically wouldn't hire him due to lack of experience. Instead we might hire some mediocre kid with the 3+ years experience and a history of guitar lessons, even though after a 100 days on the job, J.S. Bach would have been a mind blowing, mesmerizing guitar player, even if he was still a little clumsy. And after a few years, he'd be more amazing still. Yet as an industry, we focus the ability to be productive on day 10 instead of day 100 or 1000. For long term positions. Why?
How would the software industry conduct an interview for a musician? We'd ask you about all of the songs and instruments you've ever played and have you talk about those experiences. We might ask a hypothetical question about what if you had to play a certain piece, how would you handle it. Maybe we'd have you answer some trick questions: "What are the frequencies of the first five harmonic multiples of B right below middle C?"
I find this to be utter madness.
I think the best way to find a good (or potentially good) developer is to have them do what we do in our jobs, which is, given some vague requirements and some undefined period of time -- a few days or so -- write code to solve a simple problem.
And I loved the part in the article about mediocrity. I've found the best developers to be humble enough to constantly work on improving their craft. So, don't reject a candidate because they appear to "lack confidence".
If you already have enough sample code, there may not be a need to provide more.
With what level of accuracy can one tell which of the 100 applicants are going to be virtuosos three months/years down the road?
With what level of accuracy can one tell which of the 100 applicants are going to be solid _enough_, _tomorrow_?
The good but not greats are often really good at specific areas not necessarily tied to business concerns. The "greats" spend so much time on it that they end up really good at a bunch of things.
From a business perspective where output needs to be measurable/controllable you want someone either malleable enough to work on any kind of crap, or someone Soo good they can be good at anything.
The really good CSS person, the SVG animator, the functional JS guy will all be passed in favor of the malleable new grad or the industry expert. The only way is if these individuals market themselves and create a new domain of expertise by giving talks or writing books. The value is appreciated by the environment but not companies.
You cannot go to school to learn how to be a programmer, and then expect immediately to be productive at any arbitrary programming job, unless you're a talented coder. The education gap is too great. It's like medicine in which you need a few years of residency before the medical field considers you fully competent.
If you go to code school and learn Rails and React, then you can expect to be somewhat immediately productive on a Rails / React project. You can't expect anything out of them if it's not a Rails / React project. They may be able to ramp up quickly, if they're talented. If they're not talented, then they won't be able to, and the employer has to take the hit.
We will need a revolution in software development pedagogy before individual aptitude stops mattering to employers. The state of education at the moment is so bad that unschooled yet talented individuals can be much much better at fulfilling business requirements than trained and educated professionals. Try that with medicine!
Seems to me employees "are likely to walk out the door" mainly because employers view them as expendible expenses and not humans trading labor for something of value
Nobody these days would turn down a $10k raise out of company loyalty. They might for other reasons, but loyalty is absolutely not one of them anymore.
Final answer, then I'm getting back to work. Because when you take risks, you should expect a reward. If your reward isn't worth the risk, but you still take it anyway, then you're the dumb one. When you're the one offering liquid compensation, you get to decide on the risk profile of the bought solution.
Isn't the whole point of taking a risk is that there may not actually be any reward? If you expect reward every time then it's not really a risk.
Its stupid to spend the $20k, figure its "done" and then think you can just go on paying the $50k after the fact even though the employee is clearly now worth $70k.
You want a $70k talent, you can either find one straight up or make one with some mix of lower salary + training until you have one.
If you hire someone for $50k, then train them with $20k, then give them a raise after the training is over for the $20k it takes to bring their comp up to market, you're out $90k. Accounting-wise, you just gifted the employee $20k on top of his comp.
Or you can just go out and hire for $70k and just be out $70k. This is what's already being done, shifting the cost of training and education onto the ones receiving the benefits of that training.
I'm trying hard to not post a diatribe about what's wrong with this kind of thinking and just point out the errors in reasoning that come from it, but this game of whack-a-mole is frustrating. You can't demand your employer to shoulder all the risks and grant unto you all the rewards. It's unethical and leads to underhanded dealing. We want a more professional labor marketplace, not one governed by promises and half-truths.
e.g. if a company invests in a building for their office, there's always a risk that building will incur excessive maintenance expenses, become unusable because of some calamity, or that the location around the building will become a bad neighborhood and make that building a lot less useful.
i think a company can invest in, say, teaching their employees a valuable skill and then make money off that investment, even if the employee leaves eventually.
You seem to be equating bets with gambling for some reason.
Yeah good luck with that.
1. Pay them more money.
2. Give them interesting things to work on.
3. Invest in their career development.
...
It isn't "luck". Many companies just suck at that (either because they have bad leadership or their industries don't support it).
the distinction you raise is that there (apparently) is no such thing as an insurance policy that protects a company against a valuable employee's departure.
but that doesn't mean "invest" is the wrong word to use when a company spends money to educate an employee.
also, there are strategies aside from a literal insurance policy which companies can and do use to increase employee retention rates. (just like there are strategies other than insurance policies that companies can use to protect a building against damage or loss of value.)
Also the expected rewards are higher too. If a company bets $20k in an employee, the best they can hope for is that the employee does a good job. Not that that bet doubles in value.
What do you think it means from the company's perspective to "do a good job"? A developer who does a good job will most likely double that $20k in a few months.
Any place I work, it’s easier to train my replacement than it was to train me. It allows me to pick up new projects or leave for a more interesting opportunity without guilt.
Work yourself out of a job.
It definitely means I’m easier to lay off. But I’ve survived 2 rounds of layoffs before and buddy, if you can figure out how to pay your mortgage without a front row seat to watch a company crumble around you then I highly recommend it. (Also only the 1st round offers a decent severance package, and survivor guilt is no fun).
Personal finances help with that. As do maintaining relationships with people.
There might be some legal barriers to this problem like recovering the investments when the employee breaks the contract? Seems like some kind of insurance would help there, though.
Seems to work fine for athletes, actors, medical residents, certain kinds of scholarships, etc.
Pro athletes are a terrible example. There has been decades of litigation, lockouts, negotiations, etc. across almost all leagues to get to where we are now and there are many that continue to think the system is too restrictive for the players and too much in a league's favor.
A talented employee might be able to spend less time outside of work, but a dedicated one can be just as competent in the same amount of time. If you have a developer who has both, then obviously that would reduce the ramp up time even more.
I'll try that in medicine. Talented midwifes were delivering babies in the 1900s. Since midwifery is still a thing, maybe medicine is not as far advanced as you imply.
Seems like talent still plays a big role in any field.
Note that you can find "midwives" with less skill than the 1900s midwife. There are a lot of quakes out there doing awful things and getting by with it because ~80% of the time you don't need any medical intervention.
It's learning how to separate alike from different, using what you know to use something different. It's also realizing that languages vary, but you can learn the underlying concepts and apply them.
Being able to take general programming knowledge and apply it to multiple languages and projects is something you learn.
Talent may help you to learn the concepts and be more versatile, but that doesn't take away from the article's message of the typical distribution curve. This focus on "general programming skills" is fine, but lets not pretend it's "talent", because that's the whole myth!
Do you actually know anyone who's worked in these fields? Because that's not true. Wanna be an architect? Go to school + get 2 years of experience + take a professional certification THEN you can be employed as an architect. Wanna lay bricks? Get a job and you'll be taught there.
When I started as an electrician, I knew a lot about electricity already. I've always been a bit of a nerd and knew more about how electricity actually works than many journeymen I met. I knew almost nothing about how to actually put that into practice, though.
For example - when wiring an electrical outlet, you have to wrap the end of the wire around a small screw. It's obvious enough that if you do it clockwise tightening the screw holds the wire in place; if you do it counterclockwise, tightening the screw moves the wire and makes life difficult. What wasn't obvious was that instead of taking a pair of needle-nosed pliers and bending the wire to the right shape, there was a small hole in each side of a pair of wire strippers that was exactly the right size to do it: http://www.kleintools.com/sites/all/product_assets/catalog_i...
Had the person I was working for not shown me that, I would have probably never figured it out.
I think the role of a junior developer is very similar to that of an apprentice electrician, in that the dev knows at least enough to implement something on their own so long as they are given concrete tasks. A mid-level dev is similar to the journeyman; they take a partially-defined task, break it into well-defined chunks, and either implement or delegate. A senior dev is the master electrician - they decide what tools to use, make the larger-scope decisions on a project, etc.
This analogy breaks down once we start talking about software "engineers" or "architects". I can't really think of anything I saw in the trades that maps to it; it's more about identifying and anticipating important changes over time and mitigating their costs.
I think if there's one skill that might be innate and that helps people be better at programming, it's patience. Learning to program and learning programming tools is for most people a boring and extremely frustrating task. You need patience to stick with it after spending two days solid trying to debug some linker error or CSS bug or whatever esoteric programming issue you inevitably have to deal with.
Yes. Some people (both as kids and adults) seem to be innately interested in different kinds of activities. And it is perhaps impossible to separate talent with passionate interest since B leads to A.
Take the kids from my tribe, extremely passionate about patterns and things and systems and numbers and coding from early childhood, _despite_ concern from parents and teachers, social ostracization, and efforts to limit computer time. We also tend to acquire talent.
My personal take is that it means solving problems with less wasted effort. Less code (a 0.1× programmer can solve problem with 10% of the code - https://codewithoutrules.com/2016/08/25/the-01x-programmer/), but also by solving the right problem, and coming up with better solutions (https://codewithoutrules.com/2017/10/04/technical-skills-pro...).
These are all skills you can learn. And I think focusing on learning technologies obscures a lot of these skills, since they're about communication and listening and project management.
For productivity in terms of technological knowledge I'm starting to think that, since choosing which tool is more important than how to use it, a better way to get better is to study case studies. Instead of trying to learn "how can I use Mongo, how can I use PostgreSQL" you try to learn "when should I use Mongo, when should I use PostgreSQL".
I'd love to hear about good sources of case studies. http://www.aosabook.org/en/index.html is good, but doesn't cover kind of programming one would do at a company, much.
Over time I learned that the real value comes from solving the right problems, and recognizing wasted effort. It comes from architecting systems that are easily maintainable. That's what makes money in the business.
Solving narrow, intensely interesting algorithms, is a rare case that is not widely needed in the industry at large.
Aren't these all talents?
* learning many things
* learning difficult things
* recalling things you've learned when you need them
If something is a skill, one would expect all engineers to get better at it with practice. But there are many abilities in engineers that don't seem to work that way.
If years of experience meant you'd be better at a skill, then older would be able to reverse park very quickly. But without deliberate training, most skills don't improve.
* Power of Intuition, about naturalistic decision making - https://www.amazon.com/Power-Intuition-Feelings-Better-Decis...
* How Learning Works - https://www.amazon.com/How-Learning-Works-Research-Based-Pri... (my review: https://codewithoutrules.com/2016/03/19/how-learning-works/)
No doubt others can recommend more books.
Here's a video of border collies in action: https://www.youtube.com/watch?v=bpjP3mxv21s
You know, I just don't think it's realistic to expect everyone to be able to learn anything. Certainly an expert in a field can come from anywhere, but not anyone can be an expert.
I don't think you can go through those books, however excellent, grab a random name from the phonebook, and then teach them how to do differential equations. Or to debug corrupted stacks in a multithreaded C++ program.
People generally don't get good at things they find boring.
We software developers are not special. We don't have something that non-programmers lack, apart from maybe an inflated sense of self-worth.
I also think it's also considered a faux pas to actually say as much. People tie respect, identity, and self worth into intelligence a lot. It's hard to say Kimberly is smarter than David without offending people. Let alone to say engineers are generally smarter than elevator operators (to pick a mostly extinct job).
To some degree, all the interview hazing and discussion about "programming talent" is all dancing around the West's inability to discuss intelligence quantitatively and dispassionately.
To be fair, historically there has been a lot of sexism, racism, bigotry, and pseudoscience tied up in the science of intelligence. I'm not sure how to get society to re-approach the subject in a scientific, productive, and beneficial way.
Fish apparently are not good at describing water (!)
This makes me wonder 2 things
1) Why are we debating if we should keep the ~500k H1B visa holders around (of course we should) and
2) Why don't we just train the top 10% (in ability + willingness) of the ~13M unemployed people in this country?
b. If engineer salaries went up to the market clearing rate, certain business models that assume certain labor costs will become flawed
c. Who is going to pay for the training, especially in the case that all the training doesn't actually end up making the candidate any good at the job?
Talent:
1. natural aptitude or skill.
Passion:
2. strong and barely controllable emotion.
...
* an intense desire or enthusiasm for something.
...
(Also, passion in this context doesn't imply any sort of lack of control. You don't program in the "throes of passion".)