The programming talent myth

Indeed.

My spouse got sick with a pretty nasty colon disease. She was not able to do much for a long time.

Cooking got fun. I still suck, but I suck a whole lot less now. But that's not important. What matters is cooking turned into fun. I play, explore, and enjoy learning new things, which come increasingly easy. And the more you play, the better the food. The better the food, the more you are surrounded by people who enjoy your food. We will cook together now. And it's a nice evening. Get some good, or new ingredients, and go.

Chefs are awesome.

And they share too. They know the strong relationship people have with food can bridge a lot of differences. And when people enjoy the work, there is a lot of simple gratification and bonding associated with all of that. I can totally see doing that for a career and being very happy. Strange, having it all be so foreign not so long ago...

The thing is, most of us can do this. Good, basic, well prepared food is within reach of most anyone. Worth it, IMHO.

I think it comes down to whether you have high standards. Or were taught with high standards. Or were mentored with high standards. And whether as you grow you have the luxury and the persistence to keep them up. If you do, you fold in stronger and stronger building blocks that over time 'scale' and allow one to move effectively and often more quickly. If you could measure it, it would have to do with the density of the parent tree nodes within which you approach problems. Some people are lucky to have grown under rigorous conditions while yet still being exploratory and developing breadth.

If 'talent' is a function of tree node growth though, talent is not going to be bimodal. It's going to be unimodal with some long-tail bias because of the rewards theoretically of being really good at programming.

Hear, hear!

I started on AmigaBASIC and later ARexx. QBasic on later 386/486 machines. Pascal, OOTuring (a Pascal-like educational language), and C in high school. Perl near the end of high school. Python in my early twenties. Common Lisp in my late twenties. Have tried a bit of Haskell and OCaml here and there. Though I'd say I've settled on Python, C, and Common Lisp... trying to make brain space for OCaml only because I find Mirage to be such a great idea.

I've given talks on BloomL implementations, constraint propagation solvers in game level design, and have written various bits of libraries and such over the years. Nothing terribly "ninja" like here. Depending on the audience I may sound like a wizard or a clueless hack. The reality is I'm probably somewhere in the middle in skill if programming were a quantifiable skill. The only reason I can cite these things is because I tried and learned some things not because I was born with some legendary ability to whisper to a computer what I want it to do. At the end of the day they are just machines and there's nothing super-human or special about learning how they work. It just takes time and effort like anything worth doing.

The theory, as I understand it, is that without sufficient evidence we must assume that programming ability follows the same bell-curve distribution as every other quantifiable skill we can measure.

Every human ability has a natural distribution of what for a better word we can call "talent". This is as true of running or tennis as it is of coding. To claim otherwise is to tell people who aren't naturally very good at tennis that they are moral failures for not working hard enough at it, which is insulting and demeaning as well as false.

Furthermore, there is evidence that the ability to code is non-linearly dependent on some fairly uniformly distributed basic abilities. The bimodal mark distribution of first year software courses is evidence of this. It is trivial to reproduce it using the assumption that the underlying skill-set is uniformly distributed, but there is a threshold of ability below which coding becomes very hard: http://www.tjradcliffe.com/?p=1471

There is a very simple way to disprove this hypothesis: find a way to teach coding that will get rid of the bimodal distribution of marks, which has been vigorously attacked by educators for decades without progress. The things we have learned in that time are:

1) It doesn't matter how passionate the teacher is about believing that "everyone can learn to code"

2) It doesn't matter what language is used

3) It is very hard to predict who will be good and who will be bad.

Because of this, there are three reasons we know cannot be the source of the problem: the attitude of the teachers, the langauge used, or the number of years experience prior to university. If any of those were the cause the extensive research on this issue would have revealed them in the 80's.

I'm prefectly willing to believe that most people can be taught to code, and if I can be shown evidence of a teaching method that gets rid of the bimodal distribution I'll happily abandon the barrier-to-entry model I've proposed in the link above, but until then, it can't be called anything less than a plausible hypothesis. Certainly not a "myth".

This quality can be teased out of more people than we think.

A whole lot of "that quality" comes down to a couple things. One is basic inhibition. Learning to shed this dramatically improves one's potential for performance activities of any kind, and speaking in public is a performance activity for sure.

The other is coming to understand people better. Empathy is a part of this, but so is just understanding how different people are and how they respond to things varies just as much. There are commonalities, of course, but there comes a basic security from being able to read the crowd and that feedback feeds into the lack of inhibition, allowing a person to shine much brighter than they would otherwise.

This from a geek who had a fair amount of music, theatre early on. I still remember the "unlock" where I came to understand the importance of conveying intent, being humble, and not having that basic fear that locks one up so much. Failure is OK. So are basic gaffes and mistakes. People are way more forgiving than we are to ourselves.

I think Elon could improve considerably. He doesn't need to, and he's got his time priorities right where he wants them. Maybe sometime in the future those could change. Should that happen, some time spent with the right kind of people could very well open him up to a degree we may find surprising. Elon has deep passion and resolve and drive. Those things, brought out in a bit less stiff fashion may have an impact he would value someday.

In a very real sense, those that pick it up quickly, care more too. I sometimes mentor engineering types who need these skills for things like pre-sales, or to begin consulting and selling in various ways. Reducing inhibition is important. For many, it's simply not knowing what will happen, so the default is to do the minimum to limit risks and unknowns. Caring is also important. For many, the speech or show more generally, isn't core. Does not matter as much as the tech, or whatever it is being spoken.

Cracking that tends to be linked to understanding the selling of ideas, movements of money, and a lot of other things get driven by those who can handle people, and there is a science, and I would argue, technical aspect to that just as there is any thing with sufficient dynamics as to not be obvious at first glance.