The programming talent myth

In my experience it's not at all specific to programming. Other domains have their "rock-star" experts: The brain surgeons, the rocket scientists, the literal rock stars (or at least the true masters of one or more instruments, amazing songwriters, gifted vocalists), the Olympic athletes...the masters of their skill who are so good at what they do that they make it look easy. They've put in the metaphorical 10,000 hours of practice and self-improvement. They are awesome, and the rest of us mere mortals by comparison.

Programming is different from many disciplines, though:

* In programming, everyone from the student who is copy-and-pasting JavaScript into an HTML document to the amazing expert is a "programmer." There's no term for the ones at the top of the scale, no "Olympics" label, no "brain surgeon" specialty that distinguishes the top from the rest.

* World-class skill in one domain or language translates to a very short learning curve in just about any other domain. I've hopped between native apps, games, high performance servers, networking, security, drivers, web apps, embedded, IoT and machine learning, for example, and have used just about every mainstream language (and some trendy ones).

* Programming as a discipline has a 10x-20x measured productivity between practitioners with similar experience -- and the real difference can be infinite (there are tasks that I have accomplished that I know would never have been completed by some people I've worked with in the past). Though some will claim it's unique in that respect, it's not: It shares that trait with (for example) the creation of art and music. I can spend 10 hours working on something artistic, and I know artists who can produce a better result in 30-60 minutes.

* Programming can be learned with a computer and 100% free tools. You can start when you're 12 and have access to a computer, and you are limited only by your skill and imagination in what you can create. So those who have an aptitude can spend thousands of hours in practice for only the cost of electricity (after they have a computer).

It may be that Electrical Engineering doesn't have the 10x-20x relative skill effect, or maybe it does. I don't feel qualified to argue one way or another. It does seem like practitioners will specialize in a particular area, though, and tend to stick with it; correct me if I'm wrong?

Also, it's rare for someone at 12 to feel the need to compute Ohm's Law (well, I used Ohm's Law as a 14-year-old, but I'm odd that way), much less the impulse response of a filter, so for most you're learning those equations at the same time, and the difference between the best and worst students isn't measured in thousands of hours of previous experience.

>"you haven't been computing the impulse response of a filter for 4 hours a day since you were 12? There's a massive difference between engineers who have done that and those that haven't."

For the record, if you're one of those people who did start coding at 12 or earlier, it's not hard to spot another "native programmer", any more than, as a native speaker of a language, it's easy to hear when someone has learned a language as an adult. Sometimes late-learners with particular aptitude for languages can speak without an accent, but most of the time it's easy to tell. There are documented brain organization differences (fMRI) between people who learn a language before they're 12 vs after they're 14, and I suspect the same may be (statistically!) true for people who learn programming early vs. late.

I'm teaching my 10-year-old now, just in case. ;)

We eschew languages like BASIC these days, but I wonder how much BASIC, as available on Commodore machines, the Apple II, or even some graphing calculators, helped communicate this concept. I know I didn't have any problem understanding that when moving to languages that don't have line numbers (although, I did have trouble moving from the full-screen interactive editing on the Commodore to editing "files" as "the program" vs files being a "snapshot" of the program), and I've had the same experience with people who couldn't grok statement ordering. BASIC with its line numbers and simple loops with GOTO may continue to be good first programming languages because it helps with these concepts.

People always talk about pursuing coding projects just for the fun of it outside of work, but that's a pretty unusual trait for other forms of engineering.

My father has a PhD in Chemical Engineering and has been doing crude assay work for the last twenty years. He obviously enjoys and gets fulfillment out of his job. But if you asked him to analyze crude oil samples on his free time? He'd say you're crazy.

I dunno, I've been in this field for five or so years coming out of other engineering disciplines, and it always surprises me how programmers view their trade as fundamentally different from other forms of engineering.

Just a quick example -- I need to get going -- Say I have a bunch of data in a database I need to do something to once or twice, like validating imported data. It's easier to use a complex select to get it in an easy to process form, then it is to use a simple select and have a complex algorithm to process the data. Generally, given the choice, it's easier to have complicated "static" data, since it's rather static and easier to reason about, rather than complicated "dynamic" code since algorithms are generally harder to reason about.