Hacker News Reader

Comment by nilkn | Hacker News Reader

My own experience just does not agree with this at all.

First, I think we have to distinguish between two ideas here:

* The first is the question of whether anyone can learn to program. I think that for the most part everybody can, just like for the most part everybody can learn high school calculus.

* The second is the question of whether programming ability is bimodal. This is not related to the first question, and confusing the two questions is a significant error. It is entirely possible that programming talent is strongly bimodal and that 99% of people can learn to program.

I've been programming since I was 11 and have interacted with other programmers all through high school, college, and now working life, and at every single point of my career -- both academic and professional -- I have seen that some people are drastically faster and better at programming than others (but the others are still capable of learning). In introductory programming courses at college, I've done labs with very smart people who took 10x longer to figure out the lab than some others. They figured it out, but they struggled a lot compared to others, despite being very distinguished undergraduates (Goldwater fellow, etc.).

At work, we've brought on people with 10 years of experience who were 10x slower than someone else with 2 years of experience.

At school, there were master's degree candidates who were significantly worse than many undergraduates despite working just as hard and longer.

I could go on and on and on with examples. From my own life the evidence is simply overwhelming that programming talent is bimodal.

View on HN

The problem with relying on personal anecdotal evidence is that it is inherently biased. The only way to truly answer the question is find a way to reliable measure coding skill. Otherwise you find yourself making the same mistake you think Jacob is making. Using faulty data to back up an assumption.

Part of the thrust of Jacob's talk was that there is probably a whole class of developers out there who would be just as good as the rest of us but they can't get entry due to an assumption that Coding is an innate skill and not a learned one. He even gives examples like the lady who had written a working distributed GIS processing pipeline but didn't think she was a Coder.

I'm a little like Jacob in that people automatically assume I'm a 10x coder. I have a pedigree from Google. My github and bitbucket accounts are full of small libs and projects I've played around with. My code has been used by CouchDB and the list of languages I have at least surface knowledge about is huge. There is exactly one reason for all these qualifications though. I've been in the industry for more than 10 years and I was a hobbiest programmer for several decades before I was in industry. When I started learning I was doing gw Basic. My first "real" programming languages was VB6. I was a stereotypical below average programmer. I didn't know a linked list from a hashtable. All I needed to turn into the "ninja" people see when they look at me now was time.

I've met a lot of people who could absolutely reach this same level. And 90% of those people with potential resist trying because they think "I'm not really a coder". The myth really does need to die.

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".

Even if true, a bimodal distribution of suckers and winners is very different from having to meet a treshold in certain skills to be able to code at all. Not everybody can become an architect or a mechanical engineer either, but I never hear my engineering buddies talk about the mythical 10x civil engineer.

Those statistics on marks in a classroom are the first hard stats I've heard of indicating a bimodal distribution in coding skill. I have no idea where they come from though. Do you have any links to sources?

The only numbers I've seen come from the Separating Programming Sheep From Non-Programming Goats papers by Saeed Dehnadi and Richard Bornat:

> We have discovered a test which divides programming sheep from non-programming goats. This test predicts ability to program with very high accuracy before the subjects have ever seen a program or a programming language.

http://www.eis.mdx.ac.uk/research/PhDArea/saeed/

It's entertaining, but I think the double hump in first year comes more from Dunning Kruger and compulsory courses than anything else. I've heard of the same kind of distribution in first year biology classes. Even if "true", I don't think it gives us an excuse to anyone we think is insufficienty spectacular out of the industry.

Dehnadi and Bornat later walked back their claims.

http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-...

It's part a larger myth that probably needs to die also. See the book "Talent is Overrated" for a thorough and scientific evisceration of the idea.

Any chance of a two line summary or something similar?

There are two common theories on greatness - (1) it results from hard work (2) it results from natural talent. Both are wrong. Multiple studies show that high degrees of skill are the result of deliberate practice, and that its results eventually override either hard work on natural talent. Much of the book is taken up defining what "deliberate practice" is and how you can achieve it.

Do you think it applies to other fields too? For example, people who never try to do anything physically because they think they are just not "made for it" can achieve something decent, like running a marathon if they tried long enough? or learning a language, and so on?

From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience.

The most productive programmers I've met almost always had enough experience in what not to use. They have a clear focus on the simplicity of their code and their ability to reason about it. They understand the problem and the hardware as well as the language in a very detailed manner. They are by nature extraordinarily curious people.

In comparison, the worst programmers I've met were the exact opposite, learning barely enough to get the job done and never digging into the details. Sometimes they don't even understand the hardware they're using. They pick the wrong data structures, think about code first and data is an afterthought.

Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially.

> They pick the wrong data structures, think about code first and data is an afterthought.

It makes me so happy to read this.

Data in the grand scheme of things is vastly more important than code. "picking" data structures is a luxury in many cases and thus data structure often dictates the structure and expectations of your code. Data usually outlives the code. Data is effectively the earth in your code farm. Take care of it, and form it as best you can given a set of restrictions so that your program runs smoothly.

According to SICP data and code are the same! Interesting concept anyway.

http://stackoverflow.com/questions/355406/concepts-that-surp...

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...

That's like saying all Turing-equivalent languages are the same. It may be true in theory, but is hardly a useful point in most programming language discussions.

As an example of code vs. data, and this is a general statement (so YMMV) I try to structure my code such that, if there is a choice between making the code more complex, vs making the data more complex, I generally choose to make the data more complex. The code is usually harder to reason about, so it's a win if I can use a simpler algorithm.

Unless I misunderstand your point, how do you create complex data without complex code? I agree with the sentiment, but priority queues don't organise themselves. It seems more like its about the abstractions you use.

It's more of a general rule, a rule of thumb, and the difference between data and code can be very fluid, depending on the situation... But as a general rule it's worth paying attention to.

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.

I agree with your choice in the example, but I think of your select as code, not as data. So, you're moving the complex code closer to the data, but it's still code IMO.

I like these two quotes on that:

"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."

Fred Brooks, The Mythical Man-Month.

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

Linus Torvalds

> From personal experience, speed has very little to do with productivity. Productivity is a function of knowledge and experience.

As I wrote elsewhere, it's not just speed. The more talented programmers I referred to write better, cleaner, more performant and more elegant code -- and they do it faster.

> Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with and such mistakes always inflate the development time exponentially.

We can postulate all sorts of different explanations. I wasn't attempting to do that in my previous post. I was just relaying my own repeated observations that some programmers don't just write better code -- they manage to do it much faster too.

Do they think faster? I don't know. They just have a knack for programming. It's obvious to them which data structure to use, so they just use it.

Maybe it just comes down to this. If it's not obvious to someone which data structure to use and they have to spend a significant amount of time being confused about it, not only are they more likely to make the wrong choice, but they're likely to take longer too. Someone who, for whatever reason, has better intuition about how to structure a piece of code is going to be able to write it faster, not because they think or type faster, but because they just didn't even have to think as much in the first place. Consequently, I suppose that frees up mental space for thinking about the cleanliness of the code and other such factors.

I suspect those that learn to program before they're expected to have more undirected time to consider alternative formulations of their programs. People who learn later aren't performing the playful exploration that's necessary for independent mastery. They're just treating it like any other subject and completing tasks for the approval of an authority figure. I watched plenty of students learn bad habits from arrogant teachers like it was just "the way" you program. We don't have some master method of programming that can be taught that way. It's not like we're building bridges and already know pretty much exactly what we're doing. The craft is evolving before our eyes. They have to understand the incomplete state of our knowledge to know that they should seek superiority amongst potential selves and not merely acceptance from some external deity.

While there's clearly some skill that matters, there's a difference between someone that's going slow and being thoughtful (arguably too thoughtful in many cases, myself included especially here) and being just plain slow.

My idea of a slow and not particularly thoughtful programmers are the ones that really do look like someone's programming in slow motion - as well as everything else (this is something beyond the professional work I've seen). They're slow to ssh to a remote server, they're still typing in passwords again and again every day, they're slow to type out even a simple git commit message, they're slow to write out an e-mail that has very low interesting content in it. In their off-time, they're going fishing, maybe playing board games, or just constantly trying to relax and avoid thinking about anything at all because they seem to instinctively avoid anything that would be serious or present any sort of stress. To me, they're the complete opposite of the "type A" personality that's always trying to stay occupied and hyperactive. I have no problem with this life approach on a personal level, but it's a liability in a business setting wherever you are in the world and whatever industry you're in because there is just no urgency to anything and the person is pretty much incapable of handling modern professional life perhaps in general.

Heh, I know one prime example. A guy with a Masters degree that for some reason really fell in love with linked lists in one of the courses. Ever since it is THE data structure he uses no matter what.

And yes he starts coding away while reading the specs. He gets something up and running quickly, but it is rarely close to the spec and expected solution.

> Productive programmers don't really type faster or think faster. They just make far less mistakes to begin with

This reminds me of studies of chess players. It turns out that grand masters and average club players think as far ahead and as fast. The master just think of better moves.

Been screwing with computers since 9 or so, and programming since 11 or so. I'm now about 4 years into my professional career and usually get the typical "amazing programmer" remarks, that I'm fast, smart, good code, beyond my years, etc. I think that a lot of things go into it.

First, practice, practice, practice. I spent waaaaay too much time in high school writing/designing/building projects. By the time I hit university, I could write a compiler or build a web application. Old hat. That's always going to be a hurdle folks who are serious about programming are going to have to get over, I just did it early on so when I started working with others I was ahead of the curve.

The big problem I've noticed among my friends at school that floundered vs the ones that succeeded, and that of the (great) professionals I've worked with is the ability to solve problems. Some folks look at a task like "build a web application" and seize up at enormity of the task. Others, start breaking down the problem into it's component parts. Pick the front-end, back-end tools, database, and drill each piece further down. I think this is just as important, if not more, than raw coding talent, especially since strong problem decomposition skills apply across the board.

I'm regularly amazed/annoyed when folks can't solve trivial computer problems not because they are hard, but because they are afraid to jump into the deep end and start making educated guesses, googling, just plain trying. I'm not a teacher, manager, or any kind of people herder so I'm not really sure how or why folks are like this, but if you just try to tackle the problem, you'll eventually get somewhere. Overtime you build up knowledge, experience, and mistakes and you become that 10x programmer, or that 10x chef, or that 10x <thing>.

> Some folks look at a task like "build a web application" and seize up at enormity of the task. Others, start breaking down the problem into it's component parts.

This can be learned by anyone!! This is not a binary idea. The more "complete unknown" concepts in said task the more likely anyone is to seize up - good programmers (or basically any engineer) are just more practiced than most at overcoming a lack of knowledge.

I guess the ability to overcome the urge to seize up is, itself, something one needs to acquire. There is little in my life that I'm afraid to attempt. Investigate a problem and break it down into its component parts, repeat ad nauseam. I know too many folks who just throw their hands up and don't even tackle it.

Now you also need to recognize when you're in over your head (in terms of knowledge, in terms of capital, etc). I could attempt many car repairs myself, but the time and capital required is typically prohibitive. Of course one would have to first make an attempt on the problem to make the analysis.

It's an attitude, and while definitely harder to develop than technical knowledge, it's not innate ability that one cannot acquire later in life.

On the other hand, some people never develop this in their whole lives.

But if it does not come (somewhat) naturally, why would you bother to develop it?

We get so caught up in the question of "can everyone program" that we forget to ask if everyone should. There's a massive contingency of folks who couldn't care less about breaking down problems into their constituent parts and writing code to solve them.

I am a big believer that a person should try many things in varied fields -- math, art, science, music, athletics, and so forth -- and discover what they're 1) naturally gifted in and 2) what they're interested in. Then they should nurture those skills.

We would never dream of taking a person who was not gifted at basketball, and also hated it, and push them to try and be in the NBA. We don't encourage tone-deaf singers, who also don't get a kick out of performing, to become touring musicians.

In many other fields we acknowledge that a level of talent is necessary, and we also accept that not everyone is born with that talent. Further, we accept that not everyone even cares to HAVE that talent. Yet in programming we further this notion that if you aren't good at programming or don't want to learn, you're not trying hard enough, the fault lies with you - ur doin' it rong! It's the worst kind of narcissism to think that people who can't or won't do this thing we love are simply being defective people.

We're not talking about programming per-say - we're talking about being able to teach yourself, without much outside instruction.

If you wanted to learn to play the guitar, learn to take good photos with a nice camera, learn how to decorate your house in a tasteful or fashionable, basically anything you don't have any experience or knowledge in, how do you do it? The people who haven't learned how to learn either simply DON'T do it or they use their social group to find someone to teach them or pay somebody.

You can get pretty far without being able to teach yourself things, but for some skills especially those you have no idea about you have to be able to research and learn yourself.

Right - I didn't recognize the ability for what it is until I taught myself programming - since then, the amount of things I feel like I can achieve is pretty high, simply because I know "how" to learn about things I don't know about.

"or that 10x chef"

I like the chef example. I know from past discussions here that there is a large contingent of HN posters who are terrified of their own kitchen, which is a shame.

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.

That's pretty much my story too, although I didn't dig too deep because I got bored. Programming was so "trivial" for me I skipped on a Computer Science major and went with Electrical Engineering so I could learn something I didn't already know.

You think folks who can't solve "trivial" problems are afraid. I disagree. They just "don't see it" the way we do. It's the difference having talent gives you.

That's funny, I'd considered going EE for the same reason but had a scholarship for CS so just went with the path of least resistance...

The reason I think it's fear, and maybe I'm just projecting, is that anytime I didn't do something it was out of fear. Hell, that still happens in life sometimes now. I won't touch that car repair because "What if", or I won't buy that girl a drink because I suck a conversing with normal people and "What if". To add to the anecdotes, my father is a blue-collar worker, smart, very capable man who dropped out in the 9th grade. He won't touch a computer to save his life, he's of the notion that he'll irreparably break something important. Maybe folks just don't care, or don't believe in themselves, but fear stops a lot of folks from trying a lot of things. Like anything in life, it's not going to be black -and-white.

The root of this is what you point out in paragraph four: fear. My worst math students are just afraid to do anything, as if they'll break the math problem or it will bite them or they'll sustain indefinite psychological damage just by touching it. And that's a four-sentence word problem. It's about mindset rather than ability. Ability helps, no doubt, but you have to start solving the problem for ability to even become relevant.

Agreed, and I think this applies to nearly everything in life. Everyone can learn, but it takes a certain something, which you can't learn, to become great.

I spent years in life drawing classes, about 6 hours a week. There was always a clear divide between those that were great, and everyone else. Those that were great, reached that level quickly, and everyone else improved, but remained slightly above average at best.

Or, take public speaking. We can agree Elon Musk is a talented man, and he has more practice when it comes to public speaking in real world scenarios than most people in this world. However, he's just an average public speaker. A decade from now, he'll likely improve a bit, but still remain average. Why is that? Why are there high school students that can take a public speaking course one semester, and give a better speech or presentation? I think they just possess a quality he's missing when it comes to speaking.

Fortunately, everything in life requires a different set of attributes. There are many people out there that can never be brilliant programmers, and likewise, many of us could never be notable in improv, or stand up comedy.

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.

One strong indication that programming talent is not bimodal is only bad engineers (programmers in the solder language) see the world as strictly binary. As I get older and gain more experience its astounding how much of the world does not operate in a simplistic pass/fail manner instead has an optimum operating point at "muddle thru mode". Or another way of putting it is only a really bad architect/designer relies on eternal perfection, or attempting to see the world thru those very limiting glasses leads to lots of fail.

An interesting literary or fine arts comparison is the assumption that the quicker something is made, the better or more valuable it is. Obviously a xeroxed page from a Hello Kitty coloring book is inherently better than an original dutch masters painting.

Obviously xeroxing a Hello Kitty coloring book is not better if you want a painting that's worth something and in fact the process a xerox machine goes through is inherently more complex than placing pain on a canvas by means of brushes. I also don't see what perfectionism has to do with the parent or the TFA - perfectionism vs pragmatism is not the issue being discussed.

Statements like "only bad engineers ..." needs proof or if kept as an anecdote I surely hope the sample size is bigger than a couple, plus I need some criteria by which those people were classified as bad engineers.

In my experience in our industry we tend to make outrageous claims without anything to back it up, which is preposterous given how much of our jobs relies on gathering and interpreting numbers. The TFA along with the myth being discussed are no exceptions.

Kaplan-Moss has been working on high profile projects with highly talented developers for something like a decade. Due to this environment his analysis (unwittingly?) only includes data at the "good programmer" end of the bi-modal distribution.

Unfortunately for The Rest Of Us we're stuck with the occasional coworker who writes code like a misprinted example from Teach Yourself C# in 21 Days.

I think there is a lot more granularity in abilities than you are accepting. Like the article discusses, there are many different skills that make up "programming." These include writing code, architecture, data structures, communication, debugging, interface design, documentation, etc. To say that there is a bimodal distribution is to say that all developers are either extremely good at all of those things or extremely bad at all of those things. From my experience, even the best coders are still lacking in one of those areas, and even the worst coders are usually pretty good in one of those areas.

I also think you arbitrarily use the 10x thing a lot based on how you feel things are happening and not actual measurements. It is simply illogical to assume that all developer either fit into a category where they will complete a task in 1 day or 10 days...I'm using speed here because that is the metric you used in your post. I think what you will see more is a wide range of timeframes that developers will finish a task in. And with that some of them will have great interfaces, some will have terrible interfaces, some will have average interfaces. Furthermore, some will have excellent documentation, most will probably have no documentation. Some of the developers will be able to clearly articulate everything that is happening in the interface and in the code, some will not. Some will have created reusable frameworks, some will have hardcoded values. The quality of how they perform the task will be very granular based on a number of aspects, speed being only a small part.

The bimodal distribution your anecdotal evidence points to is very lacking in the full scope of what makes up "being good at programming."

I agree with you. This article is incredibly, just woefully dead wrong. I have interviewed hundreds of programming candidates. Reviewed thousands of lines of code. Programming is an aptitude that requires passion. The only programmers who are good are the ones who love to do it. If you don't enjoy it, find another profession. Because all the things he said aren't true are.

If you don't want to be constantly learning then this is the wrong profession for you. You have to stay current, or else you will slide from good to mediocre to fired within the span of several years.

I don't stay current (fads fade and I've seen too many to care); I have little passion for programming after 20 years; and yet I'm still hired with high contract rates to help people out of development holes.

The plural of anecdote, however, is still not data.

I'm not as sold on passion as a requirement as I was. Too often, it's just monomania or obsession in a fancy outfit. See also: Programmer Passion Considered Harmful: https://news.ycombinator.com/item?id=9211214

I think the source of your confusion is based on a false assumption that speed has anything to do with programming skill or quality of output.

I've never met a really good programmer who cared much about how quickly she finished a project. Only about doing it right.

On the other hand, I've met a lot of bad programmers who were really concerned with writing code quickly, or bragged about how fast they could code, who's output was terrible.

Now it may be that a skilled programmer comes to an answer more quickly than an unskilled one. But it's also true that a sloppy programmer comes to an answer more quickly than a careful one.

I agree with most of what you said, except that perhaps the distribution is a little more complex than bimodal.

Perhaps it's multi-modal, with various discernible leaps in performance. (There's a big gap between "Green", "Good" and "Rock Star", so I think that there's at least 3)

Any distribution can look multimodal if you under sample.

True. My contention is that learning happens in steps, it's not linear. This is especially true in programming. So rather than a smooth curve of talent, there are plateaus that people reach.

I would love to see data on this. Who knows, I might be wrong. (Wouldn't be the first time - even today)

I think there's also an in-between for Green and Good, which is Effective... There are a lot of tasks that don't need an elegant solution, only a working one. If your solutions are broken up pretty well, where a given piece can be updated or rewritten without having to refactor everything, it makes that easier, and makes a project work better with multiple developers of varying skill.

Is speed really the most important metric?

It's not just speed. It's everything. They're not just faster -- their code is cleaner, faster, more elegant, and better according to most metrics you could think up.

A measure of the elegance and cleanliness of code is so arbitrary in our industry that it's useless as a metric.

Faster is concrete enough to be useful though.

How do you measure speed though? Speed to hit the done button or speed to get to production bug-free? You aren't really measuring speed accurately until you account for all the downstream time, and even include time for problems found in production. After all that, you need to account for any technical debt that was accrued as a result of going too fast to get this specific task done. Almost every day I run into a 1 hour fix that is now going to cost us 10 hours to recover from.

Are some developers faster than others when you include all these concerns? Certainly. But measuring it is so incredibly difficult and error-prone that we mostly just stick to some emotional impression of how fast someone is.

I was actually referring to the runtime performance of the code not time to completion.

Perhaps not the most important but it is important. Whatever the job, if you can do it faster you have more time available to do it better.

Speed in every industry, including programming, is part of the sauce not the special ingrediant as far as I've seen.

All the way to working a line in a factory, the speed of the line is constant but the accuracy on top of speed is what sets the best apart.

Anyone can go fast and make mistakes, those who have figured out a method that works for themselves and keeps up with the pace (or keeps ahead) and puts out a high quality product at minimal mistakes is what stands out.

The evidence you offer does not go so far as to support an inference of bimodality, only that there is some sort of broad distribution. That is as far as my personal experience of the matter goes, as well.

Some teachers in the field think they see bimodality in their classes, though there is some evidence [1] that this is a result of teaching to those with prior experience. One might guess (but cannot assume) that this carries over to the workplace, but also that it could be mitigated by better teaching.

[1]Anthony Robins. Learning edge momentum: A new account of outcomes. Computer Science Education, 20(1):37–71, 2010.

> 99% of people can learn to program

A good sixth of people are nearly functionally illiterate. I'd say well less than a third of people could ever write a real program.

Is that because they're unable to learn, or because they haven't been taught?

Not only that, but most people are utterly uninterested in programming. Talk to almost any teacher and they'll say that uninterested students don't learn well.

"Real program" treads close to No True Scotsman.

99% of people can learn to write hypersimplistic programs, with an absolutely maddening amount of hand-holding. Those people will never be employable as software writers, because they cannot be independently productive.

My own father can program well enough to impress all of his friends with his old-man's technical savvy. But whenever he tries something even slightly difficult, he needs my help. He can do well enough to make websites that include a few simple interactive features, but he will literally beat his head against the wall for days trying to solve something that I can fix in 30 seconds.

I can't explain that disparity without employing the premise that some people are naturally better at coding than others.

The ultimate irony is that my mother is a retired lawyer who specialized in draft legislation. If she cared to, she could probably learn to program ten times as well as my father in one tenth the time. She does not care to; she prefers to play video games. (So do I, for that matter, but I need the money.)

Lawyers that work in contract law or draft legislation are essentially writing programs in (nearly) natural language that execute on a human-based operating system, with non-deterministic processors.

Reply on news.ycombinator.com