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.
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.
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.
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.
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.
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.
"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."
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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'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 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 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)
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.
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)
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.
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.
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 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.
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.
If you started programming when you were 12 and you've been programming for fun more than 4 hours a day every day since then, you are going to be drastically better than someone who starts programming in their first year of college and only does it to graduate. It feels like a bimodal distribution because you then get both kinds of programmers interviewing for jobs at the same age when they graduate from college and one of them is going to feel drastically different than the other.
You created a bimodal distribution because you only talked about two types of people. Some people start later in life, but have an incredible talent for programming. Some people start early because they really like programming, but never achieve the highest levels of proficiency because they lack some natural talent.
Like most things, programming is a mix of natural talent and practice. Some people have incredible natural talent and will succeed no mater when they started. Some people will achieve a very productive level of programming with less natural talent because they put in the work to achieve it. There are more than just two archetypes that make up the landscape of developers.
Then, there are those profoundly incapable of programming. My high school classmate who seemed to be getting it, but on the 1st assignment came to me and asked for help. It became clear he had no concept of the ordering of statement. He wrote them like math formulas, and didn't understand that they got executed in order.
Fast-forward 3 years; both of us in college. He had to take a programming class again. I met him in the 'computer center' (they used to have special buildings for using computers). He asked for help again; he still didn't understand about statement ordering. I smiled and suggested a tutor. There was just nothing I could say that would get through to him.
So no, not everybody will learn to write computer code. Some people are tone-deaf too, and will never sing nor play an instrument.
> Some people are tone-deaf too, and will never sing nor play an instrument.
That's quite a telling statement. Actually, there are very, very few people who are _truly_ tone deaf. Since intonation is used extensively in nearly all human languages, anyone who truly is 'tone deaf' will have quite an issue in communication. Nearly all the time (and tbh I think it probably is just all the time), they actually just have an 'untrained ear'. Like most people in that kind of position, part of the reason they are in it may well be because they were told when they were young that they weren't any good, and decided to put their efforts elsewhere. And like all people in that position, you can get better. Will they be the next Miles Davis? Probably not. Will they be able to play in a band with their mates? Yes.
A century or two ago, around the time literacy started to become a thing most people could attain, people must have had a similar attitude to yours with learning to read. Some people can read, others will just never learn. Their brains aren't designed for it.
This is how stigmas form. Coding is not that much different to other human endeavours.
All I'm saying is, if you plan on becoming a teacher ever (in the widest possible sense), you're really going to have to re-think your attitude there.
Yet people think different ways. Its easy for a musician to think "everybody knows how music works; its easy for me so its possible for everyone". The evidence suggests otherwise.
Actually, that's really not true at all. In my experience studying music, and surrounding myself with musicians, nearly every professional musician knows that understanding how music works -- and becoming proficient at performing it -- only happens through intentional practice. Nobody starts out as a world class musician, no matter how talented they are. Every new musician who picks up a saxophone, for example, has a hard time playing in tune. It takes time and dedication. To musicians, music is easy because they've earned it, not because of innate talent.
Sure, some people might have "innate" talent in regards to music, but that just means they'll progress a little more quickly. But they still need to progress. And that takes work.
But it's possible to get better at something with practice and to think or say otherwise is toxic. If you think it's possible for someone to rethink their attitude then you already agree with me.
Sure; but there's talent and there's complete lack of talent. Start with something you have a particle of skill at, is yards more satisfying. At some point, its beating a dead horse, to torture yourself with practice at what you stink at.
Talent scouts do a good job finding young people. They pick ball players, runners, divers, gymnasts early. Its not magic - they show early promise. And so many times they pan out. That probably means that talent is real and actionable.
Not really. E.g. there's no ordering in function composition that isn't also in high school math. Also, you shouldn't depend on e.g. maps processing elements in a given order.
My impression is that statement ordering is easier for mediocre but competent programmers than it is for excellent programmers. The reason is that writing correct imperative code is non-trivial, but writing correct-y imperative code is pretty easy. So someone who's carefully thinking things through while learning will have a more difficult time with simple assignments, because -- at least while learning -- they're essentially trying to construct the correctness proof in their head. And that's pretty hard for imperative code.
Then declarative programming, maybe? You don't care as much about execution order when doing declarative programming like Prolog. (unless you're writing code "procedural-style")
Given that I have a hell of a time wrapping my own (algorithmic-oriented) mind around that kind of programming, that's not necessarily a weakness. It is an interesting contrast in ability though.
It became clear he had no concept of the ordering of statement. He wrote them like math formulas, and didn't understand that they got executed in order.
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.
I wonder too. I'm no help; it never occurred to me that programming was functional. I took to 'imperative programming' like a fish to water, at a very young age (elementary school).
> It became clear he had no concept of the ordering of statement. He wrote them like math formulas, and didn't understand that they got executed in order.
That's not an ability issue, just a knowledge issue. Coming from math, you'd assume there is no evaluation order.
I think the point of the statement was to show it was a ability issue because knowledge can be acquired and presumably abilities cannot. So the second time the friend asked for help with the same issues it should not have have happened if missing knowledge were the only issue.
I was not there and my opinion on this issue is complex, so I will just step out now.
squeaky has it exactly right. No matter how many times I said "they get executed in order. There is a state to the computer, and these statements modify that state sequentially", he just wrote random statements down in no particular order. I never saw such profound inability to understand programming.
You needed to be able to find a way to relate the machine model to him. There must be some kind of everyday task that could be used as an analogy. Also, because code looks kind of like maths this person was engaging a math mental model. Therefore you needed to say, (1) it's not like math, stop thinking like that and (2) it's like a recipe for a cake where each step must go in a particular order (or whatever analogy works! Maybe multiple analogies!
That said, I was asked to give computer grinds to a friend and the guy could just not grok it. But then again he had zero motivation and interest. Lots of people who say that they are bad at math/programming have no interest in making the effort to becoming even a little bit proficient.
I really really would like to know if there are people out there who want or would like to code but for the life of them they cannot wrap their brains around it. I think this is a very important question because I can imagine future social arrangements and scenarios where not knowing how to code will be highly socially disadvantageous.
All that is true, sort of. OR you could find somebody who gets it easily, and spend your time teaching them. There are essentially an infinite number of people in the world to teach.
Sure I can. That's part of the definition of IQ - how much explaining is needed, how much time it takes to understand. I can explain away this guy's inability as a different way of thinking. But you could also say, he had a low IQ. Except he was smart in other ways.
This seems like a form of elitism very specific to programming.
I graduated with a degree in Electrical Engineering, and barely did programming until I began my first job out of college. In many people in the programming space, I see contempt that coding was something I didn't start until later in life. When I interviewed for Electrical Engineering positions, no one ever scoffed at me, "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."
I think it really comes down to how much enjoyment one gets out of programming. If you thoroughly enjoy the process, you are more likely to put in the time and effort (in fact it will feel effortless), and you will be thinking about it all the time. Then there are those who don't mind programming, or maybe even see it as a chore, but choose to do it anyway.
I sometimes see the amount programmers believe they're supposed to enjoy their job as unique to programming.
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.
You know it's funny I agree. When I was working as an EE no one ever gave me trouble because I wasn't building circuits or filters or doing RF design at home and because I didn't want to think about it when I got home. I keep seeing this attitude in the software engineering sphere that you have to totally embrace it and have all sorts of side projects and it's encouraged to more or less dominate your life; I can't imagine this is healthy for most adults.
I think this is because a lot of computer work isn't just engineering (although there is a large amount of that mindset involved), but it is a mix of engineering and art. One thing to compare it to is woodworking. Many people who are good at it will go into something like cabinet making, but they will still have a lot of personal woodworking tools in their garage. There is something about creating something that, even if the process itself isn't really enjoyable, the final result is.
I've heard the same. There's an opposing group to that: writers.
Read any interview with a novelist, screenwriter, short story writer, etc and most will say it's something they hated doing but were glad to get done.
Pushed further though, I've seen good advice in some of those interviews which is to try to learn to enjoy the process, as what happens with the finish product is usually out of their hands. I think that's pretty applicable to a lot of other fields as well.
Yes! Like musicians that have tunes running through their head constantly. Or poets that turn every phrase over in their minds.
Did you ever dream of debugging your children? That if you could only find the right breakpoint to set, you could adjust them and fix something? Then you are truly a programmer.
Exactly. My dad is a musician, and I always wanted to make music, but I just don't have that thing where I'm always thinking of new melodies or beats or whatever. I know that I could not make music on par with the people in the world that do this like my father. Unless I have some previously undiscovered stroke of genius with music. But that is very unlikely, and still the standard comes down to "How much do you enjoy doing X?" that really determines how good you are or will be at X. I fucking love programming. That means I've got the capacity to excel at writing code. But I'm only okay at making music, and I only really listen to music when I code. So there is diminished capacity for me to be a rock star. Sufficiently diminished capacity that I probably will never be a well-known musician, let alone Michael Jackson.
Did you ever dream of debugging your children? That if you could only find the right breakpoint to set, you could adjust them and fix something?
Or maybe it's a sign that you should take some time off coding and not take your work home and give the other half of your brain some room to wander and explore space and time.
Exploring isn't a passive activity, everyone has their own way of discovering the world and I don't think anyone can claim theirs is superior.
Furthermore, being able to transfer concepts from one activity to another is a clear sign of intelligence: applying an idea to 1-dimensional text and then applying it to social relations isn't a passive activity either, it shows deep understanding of the idea.
I have programming dreams from time to time. But I'm not sure that "programmer" is the first word I'd find for somebody dreaming about debugging his children.
I think its a good word for somebody that has a head so full of programming, that it leaks over into other parts of their thinking. Like musicians that see a rainstorm and think of music.
That is big of you to admit it! I too have 'programming dreams'. My buddy Tom and I share this problem. We agree, they are troubling and I wish they didn't happen.
I don't think it's elitism, it's just that programming offers a unique opportunity to do this stuff from a very early age from home and the end results is some people end up being very good at it "early" in their career.
Unfortunately you couldn't start "computing the impulse response of a filter" when you were 12 but if you could, and you continued to practice it daily, you would be very capable compared to people who just started in university.
You're demonstrating the exact syndrome the story discusses: conflating the ability to write code "well" with all the other things one does as a software engineer. The article goes into more detail, but I do a fair number of things every day that do not involve typing in code on a keyboard.
Going further, I would argue that most people I know who've been programming since they were 12 weren't even writing very good code at 22 (or whenever they left college and entered the working world). It's vanishingly rare that people were writing flexible, maintainable code in their teens. It's much more common that they were coding to scratch an itch, and that their code only solves the pieces of the problem they cared about, and probably not very well.
This - that it's extremely rare to even be able to think the right things to produce maintainable code at that age - is why I've long thought that 12-15 is the right age to teach assembly language.
At that age, your code is going to be a mess no matter what tools you use, so you might as well have an excuse.
(Seriously: there's some brain development that doesn't happen until the close of puberty, and I believe that some of that is necessary for most people to plan and write maintainable code)
It's specific to programming, but not exclusively to programming; there are a few other areas where "you haven't been doing this since you could walk? Too late to be truly good":
For the most part companies doing EE work seem to rely on the big three companies making EDA software to do tech development.
On the web and in app development, there's a far greater variety of technical bases to begin building atop, and a lot of web fundamentals that have developed culturally (rather than out of scientific or mathematic bases, where it can be clear your tools are helping).
A sometimes seen result is that those communities of developers that are "well served" by platforms perhaps "shielding" them from the sticky intertwingulated overwhelmingness of choices and protocols and systems often can't relate, don't relate to the wider body of codecrafters.
Ability to harness the best or biggest slices of culture well is a huge part of programming, and that requires more than being really good or really smart: it requires a will and energy to chase, and to always be chasing, keeping yourself unrooted from what you merely know or how you've done it. That doesn't justify a bimodal view, because there are certainly all kinds of ways people come about to programming, but I think in programming it really is different- since everything is made up and abstract, we're still figuring out general shapes. It's all a social milieu, and it requires paying attention to establish and keep authentic roots and identity, roots you'll need to contextualize what it is you do and what's coming down the pipe. Calculating impulse response is a hard task, but it has a mathematical fixity with no compare to the computer arts we use.
It's also been an extremely exciting time watching programming's recent decades. So there is some elitism of simply- why haven't you been here, enjoying the hell out of this? I think it's ok to feel that inside in a general way, I don't think that can be stopped or avoided, but how we reconcile that with the world without falling into the abundant moral hazards, how we still be good- it's doubly hard to reconcile yourself when the feeds are rife with people berating and assaulting tech culture, when you can get lost in these other people fights.
As a programmer, keep an open mind and accept many types of people as peer. As a person in the world, keep an open mind and accept that programmers are still quite high on some cyberspace utopianism and a precambrian-esque explosion of capabilities, and that just as much as you feel alienated by them, they feel alienated that a wider world excuses itself from recursing the depth and breadth of what enraptures the techie. 'The weirdo is just as scared of the normal person as the normal person is scared of the weirdo'
>This seems like a form of elitism very specific to programming.
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.
He does not deny that there are people on the tail of the normal curve. But his point would be that there are more people that started at 12 and programmed a couple of hours on the weekend v. 4 hours a day. And there are still more than that that started at 15. This creates a normal curve, not a bimodal.
I'm curious if anybody who starts programming in college would ever write such a message. I think "dusklight" started programming around 12 and programs for fun more than 4 hours a day.
I was doing x86 assembly as a teenager and perform terribly compared to at least one person who started in college.
Don't underestimate by how much the speed at which you learn increases as you get older. There's lots of amazing musicians around who only started playing as adults, for example, because aside from a couple of kid geniuses, learning an instrument when you're young is just really, really hard.
I'm not thoroughly sold on the "too old to learn" adage either. I think it has more to do with time and focus. Since moving into the stage of life in which I have a family and more responsibility in my job, I have considerably less time to focus on learning a new instrument or music theory or ______.
I have no doubt that there is an age, beyond which, your brain has degenerated too much to learn. But, I'm not convinced it's as early as 50's or 60's. Hopefully, with better awareness about nutrition, exercise, and stress, we can see people learning music instruments well into their 80's.
b) Instead of 10 years experience, maybe someone has 10x 1-year experience.
c) To learn theory, data structures, etc maybe university/company provides a better environment than your PSTN connection on the internet (at least that's what we had when I was 12).
d) When you get hired in a new environment, almost certainly you will face a codebase that you were not aware of. What mostly matters is your ability to generalize your experience.
Because of at least (a) - (d), the condition in the first part of your if statement, does not necessarily imply the second part.
I couldn't agree more. When I first started out studying CS I was constantly afraid that I wouldn't be able to cut it because I didn't always immediately see how to solve algorithmic problems or write code that would work. I got bogged down in thinking about programming as a problem of learning syntax, and missed 'obvious' things. I couldn't reverse a string or write FizzBuzz and in fact part of the reason for that was that I was so sure that programming was a magical ability that I didn't have because I compared myself to people who had been writing code since their childhoods, and this created nerves which made it hard to really think about solving these problems instead of feeling helpless when I didn't immediately 'know' their solutions.
I powered through that and ended up doing very well in my CS program at Northwestern, and now am a professional software developer that my peers consider to be a 'rockstar' programmer, although I still contend that I am mediocre and there is always SO much more to learn. At my job I frequently mentor our college interns, and many of them when they come into the job would be laughed out of the room by 'good' programmers, but after a little bit of mentoring and consistent daily practice on the job, in 2 months they emerge 'rockstar' programmers themselves, and in reality they are still probably about average.
Most of the 'bad' programmers many of us come into contact with are just farther behind on their journey to being great software developers, and may only be as bad as they are because of fear to ask questions and be judged by those who think there are only 2 types of programmers.
This is a common problem in art, music, sport and programming - you have an expert trying to teach newbies, and they say "just do this". The newbies have no idea how to begin to do it and the expert knows it so intuitively they cannot break it down further. Everyone ends up staring blankly at one another.
Getting people past that point seems to be a skill of its own. Certainly it's not been easily packaged for programming. Learning involves a lot of guided experimentation, and keeping the student's morale up is just as important as the material itself.
I find that it's commonly best to learn from someone not too far past your own ability.
My father is a very talented pool player, but he was not the best teacher until my own skill became pretty considerable.
He's so far removed from the things that are important to beginners. He says "you have to hit that shot with a medium-power, really good draw stroke." They have no real idea what medium power is, and no idea what a stroke really is, and possibly can't draw the ball.
It's possible he's just a poor instructor--that's probably not very related to his own playing ability. Some people can convey complex ideas in a very simple manner, and I think they make the best teachers.
I've called this concept in teaching "remembering the struggle". If a person is so far removed or such an expert in a field, they may not even remember what a person trips up on when they first get started. They may even have been so talented they didn't even been tripped up at all. Lacking this ability to empathize and relate can make teaching very difficult.
I remember very well the painful process of my dad trying to teach me to drive stick shift (on his new truck). He never mentioned that the clutch had a catch point (that wasn't all the way at the floor), but gave instructions that really hinged on that fact (give it gas, let it out slowly at first, etc). After an hour of us being very frusrated, I went out alone and taught myself.
I later taught two friends, explaining the clutch's catch point, and they were 'getting it' within a couple of minutes. A few accidental stalls, sure, but they understood why. 20 minutes or so and they were legitimately ready to drive on the road (both had been driving automatics for years).
My dad had already been driving for 40 years, he totally forgot the catch point even exists.
>Most of the 'bad' programmers many of us come into contact with are just farther behind on their journey to being great software developers, and may only be as bad as they are because of fear to ask questions and be judged by those who think there are only 2 types of programmers.
In my experience I'm not so sure about that. I've meet (and worked with!) bad programmers very much my senior. After working with them I know why they are bad - they don't learn. Even with asking tons of questions and having their work critiqued constructively. I don't know why this is but I've observed it a few times. It seems some small subset of people, no matter how much they do something just don't get better at it. They spend 20-30 years writing software like an amateur who just learning. Someone I know said about this - "experience isn't a measure of time spent doing something."
Well that's the only metric that most of us should be considering...whether or not someone considers that they have more to learn. If they don't, they will never be great. But anyone who wants to learn can become a good programmer, and being called a 'bad' programmer early on just because they haven't reached that competency yet is the problem that we're really talking about.
The bimodal distribution that people talk about seems like a dramatic simplification of a series of continually developing sub-competencies.
So, the only real weakness I've found is when someone considers themselves to be done learning. At that point, they are basically done being a "programmer".
The difficulties that beset you initially are not the same as those that make programming effectively a difficult task. For anything but toy problems, 'soft' skills like being able to organize your thoughts and having good judgement become important, and not all quick-starters make the transition easily.
That programming is a talent is not a myth, and while my life is currently devoted to developing a platform to encourage more people to learn the basics of computer science, I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter."
Good programming is an art, and requires talent on the part of the programmer. There's nothing wrong in saying that. The issue is that there are thousands and thousands of potentially great programmers who simply never try programming, just as there are thousands and thousands of never-will-be concert pianists. But many children take piano lessons just in case. Why can't they also take coding lessons? Just to see?
> I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist"
I would certainly say "anyone can learn how to code" in the same way that I would say "anyone can learn how to write", or "anyone can learn to run", or "anyone can learn to play piano".
I wouldn't say "anyone can learn to become a concert pianist", in the same way that I wouldn't say "anyone can learn to become the technical lead of a software firm that revolutionizes the industry" or "anyone can learn to be an Olympic sprinter" or "anyone can learn to be professional novelist".
But programming is, IMO, a bit like writing (though certainly not as foundational) in that you don't have to be a professional programmer to get professional benefit from having some understanding of programming, just as one doesn't need to be a professional writer to get professional benefit from writing (even piano is a bit like this, though the domain in which it is beneficial is somewhat narrower and definitely centered in a different place than where programming is beneficial.)
I'd say it's all a question of bandwidth. Geniuses just have enough capacity to converge quickly. "Incapable" people are below the threshold, so everything ends up as a cache miss, lock contention, pipeline flush; progress is so slow that they're directed onto other things. Wise people can attempt to craft their learning to converge smoothly too, they have patience to focus energy and wait for data to emerge, because they went through the slow discovery before, like a longer timeout.
With time you may grow very impressively, realize that stuff eluded your senses and mind, eureka, but time is an expensive resource.
I think this is really the key here. There is surely a natural, in-born talent for writing code, as there must be for every activity a human can engage in. But I think it's possible for people arrive at the set of circumstances that takes them from okay programmer to "talented" programmer. Time and focus I think are key, as you mentioned. People that don't dedicate enough time or focus to this craft will never achieve a high enough level of productivity to be called "talented", unless they have that natural, in-born, freak capability to code. But even these people are just okay programmers on days they can't get into the flow. Anyways, I think circumstance plays a much, much bigger part than most people realize.
Yes, I don't dispute the fact that there are some innate trait, more fitting brain structure, differences in sensory sensitivity (stupid example: perfect ear) that lead to better 'performance'. But a lot of said impossible tasks are named so because of a lack of understanding and thus a difficulty in teaching.
So far music school way of teaching is by sitting you on exercises while someone verify the output. That is not teaching per se, it's a black box system that has seen somehow regular results. Kinda like making glass, there's a procedure for that, but what really happen at the molecular level is still blurry.
With time the student's body and mind change and he gets skilled at it. How does he explain it ? does he have words to communicate his feeling to a newbie ? Never seen so so far. Recently some violin teacher was praised because he discovered non-linearity (the fact that inertia in normal speed gestures is not the same, thus learning technique requires you to fake inertia by allowing acceleration at slow speed, which means exaggerated movements). Still a shallow discovery to be honest. It doesn't really describe how to create and sustain this kind of inertia between multilimb chains and how to attempt it pleasurably.
Back to code, similar issue is present when one of the most effective (and pleasurable) way to learn the art is by pair programming (with a mentor or even a same level pair). It shows that some notions are still not taught properly in schools. Maybe the system is already at peak and there's nothing to change that would lead to better progress.
Is there a belief that anyone can learn to play the piano? I can't. I struggled for many years trying to learn various instruments. I failed miserably no matter how hard I tried. I tried and I tried, I really wanted to be able to play an instrument, any instrument, but I was unable to. I'm not dumb, I am a programmer, but music was just something my brain couldn't comprehend.
Of course we also have to define what exactly is "able to play the piano" and what is "able to program"? If know how to write "hello world" does that mean I know how to program? If I play a couple cords does that mean I know how to play the piano?
I do believe that anyone can learn to play the piano, although I would admit it's harder for some than for others. A lot of it has to do with finding the right teacher though.
What exactly do you mean by you were unable to? People have different ideas of what it means to be able to play the piano.
For classically pianists, it just means you can read notes and play the corresponding notes. I imagine anyone could memorize what notes correspond to what keys and, as long as they are physically capable, be able to press down on those keys. You might not be able to play any arbitrary piece, but I think most people agree that just because you can't play Rachmaninoff Piano Concerto 3 doesn't mean you don't know how to play the piano.
I actually never tried to play the piano, just the flute and later percussion.
>For classically pianists, it just means you can read notes and play the corresponding notes
Couldn't do that. Couldn't read notes, not even very simple pieces. Reading which note was what, them and then thinking about the corresponding fingering, doing it while following along with the beat... nope, never happened. It wasn't like I didn't practice either, I did. I was so so so determined to be able to make music, it was something I wanted bad, but no matter how hard I tried I just couldn't, my mind didn't work that way. I had the mental capacity to remember how to play only a couple of notes at one time. I then went to trying to play the drums since there was no remembering which fingers go where. That, while a little easier, didn't work either. I couldn't keep up with the proper timing of the notes.
You could just say I had terrible teachers (public school) but I don't believe that. I gave up after years of trying, it wasn't like I had a mental block to learning. I practiced on my own time too.
I also was unable to ever learn my multiplication tables.
I am not stupid though. I don't have a learning disability, I got great grades in school. I write software for a living. I have a lot of intellectual hobbies. I love talking about math and probability with friends. Nobody who knows me would tell you I am stupid.
I've also seen people struggle just as bad with stuff that comes naturally to me, so I understand some people's brains are just wired differently.
>I also was unable to ever learn my multiplication tables.
>I don't have a learning disability
Maybe you don't have a learning disability, but you definitely seem like you have some sort of mental block that is preventing you from being able to learn certain things. Maybe things you consider boring, and you can't focus enough on them to get past them?
There's no reason you couldn't have a learning disability. I was one of the smartest in my class and turns out that I do indeed have ADHD. I've also never been able to learn a musical instrument, but I've only put one or two months of continuous practice into them before giving up for another year or two. Barely enough to get muscle memory working for me.
Edit: From Wikipedia: "Attention-deficit hyperactivity disorder (ADHD) is often studied in connection with learning disabilities, but it is not actually included in the standard definitions of learning disabilities. An individual with ADHD may struggle with learning, but he or she can often learn adequately once successfully treated for the ADHD." Ok, so it isn't a learning disability technically, but it's been a barrier to _me_ in learning an instrument.
Hm it sounds like because you were unable to learn the flute/drums despite not being very motivated, you don't think everyone can do it. I think this is a fair observation, but I also do wonder if you tried a different approach whether you would be able to learn. I hope that didn't offend you, you certainly sound very hard working, and I wonder if I might be able to help if you were still interested in trying to learn an instrument.
It seems like you felt overwhelmed by all the various parts of making music. But since you are just starting and having trouble, I wonder if it would make more sense to try to isolate the different things until they become easy enough that you can do them together.
Please forgive me if you already tried this, as you didn't mention whether you had a teacher and what music you were trying to play.
For example, if you had trouble with beats, you could try practicing the beats just by tapping your hand or singing or something else. I was ridiculously bad with rhythms (and still am?) so I have a lot of personal experience with this one.
Then, if you have trouble reading the notes, you can just write them down in a way that's easier for you to read. There's no shame in just writing down the note names! Alternatively, you could just try to memorize a single measure and practice that one measure. Again, I found myself doing this all the time, especially because on the piano you have two hands to read notes for. Of course, what might make even more sense is if you just picked easier music to play.
I think for fingering, the same advice kind of applies.. you can pick easier music, or just memorize small sections.
In a way I feel like you could use this same advice for programming as well. If you pick a super huge project and only gauge your progress for that whole project, you might get overwhelmed and feel like it's taking too long, which stresses you out. Alternatively, if you break the project down into manageable chunks, you feel good about your progress!
At least this seems to have worked for me! I don't know if this will help you at all and I apologize for being so stubborn but I really don't believe you are unable to learn an instrument unless you have some learning disability.
I think what happens is people try to formalize all the fun out of music because they don't know any better. They fall back on the broken rote learning they got back in grade school, and the results are predictable.
I usually write out songs in my head as changes in pitch, then work out notes and scales later in my DAW. I learned to keep time by drumming on the wheel with music when stopped in traffic. I can't remember scales for long, but I made a point of committing the notes of the keyboard keys to memory so I can quickly memorize a scale and experiment with melodies.
I've tried very hard at some things and failed miserably. I've tired hard at some things and had great results that surprised even me. Those are facts.
It is correct that I can't do things that I don't have the ability to do. There's plenty of things people can't do but that doesn't mean everything someone can't do can't be learned. I can't run a 10k but I'm sure I can if I wanted to, tried, and trained for one I could. There was a time I couldn't write a line of code but that didn't stop me from learning or trying.
I believe many people have something or another that is extremely difficult to impossible for them to learn no matter how hard they try and its different for everyone. Most people don't have an interest in trying things that don't come naturally to them so many times people don't experience that so they can't imagine someone else experiencing it.
(Apologies, I'm really replying to your post deeper in this thread -- HM isn't giving me a reply there.)
On learning music, I'm wondering if you ever tried to learn to play by ear? If someone beats out a rhythm, can you repeat it?
One of the weird thing about most music education (at least in the US and Canada) is it focuses heavily on learning to read music. But if you poke around the corners of the music world, it turns out that loads of fantastic musicians have never learned to read or write music. One of the features of written music notation is it tries to reduce musical rhythm to math, so it might make sense if both things were weak spots for you.
(What do I mean by "tries to reduce"? Consider, for instance, swing. Lots of times the ratio of duration of the lengths of the two notes in a swung pair varies pretty continuously depending on how fast the music is going.[1] There's really no good way of notating that concept in standard music notation, other than just punting and writing "Swung eighths".)
Learning a musical instrument is hard work, but yes anybody can learn to play on an intermediate level. It takes zero talent to do that, but hours and hours of practice with a metronome.
"Able to play the piano" means you can look at a lead sheet with chords on it and play basic accompaniment to a melody. That's not difficult at all once you've learned how to do it.
I would say "able to program" means you can take an arbitrary set of feature requirements and write a program that fulfills those requirements.
It's all very interesting. I believe programming is less obscure, less challenging for the senses thus easier to make progress in. In the end not everyone will be able to invent a new paradigm, or even solve hard problems in code.
I still don't understand music, but I've been through long plateau followed by big insights. Same as in programming, some ideas were out of reach for a long time.
Doing things in time is already music. What most people want is a tiny bit of complexity, overlaying melodies and rhythmic patterns to tickle our senses. But to my deepest understanding, it is mostly the state of flow where you feel locked into the invisible energy of music. Maybe it's a high sensitivity between your interactions and the actual waves caused by your instrument, and an inner knowledge of how to keep that vibration moving without choking (think taking successive perfect curves with a car).
"Hello World" is roughly equivalent to playing a random scale. If you can memorize a scale (even briefly), you can play the piano. You might not ever manage to compose a legendary piece of classical music, but you can impress your friends by jamming with a man jue or a gambhiranata.
Most of what I make is mostly or completely electronic, and I can barely listen to classical. If you think "learning the piano" and "playing piano music" are synonymous, that might be the problem. You can make a lot of interesting sounds if you hook a MIDI keyboard up to a computer.
(aside, the best investment I made was Piano Companion Pro. The scale DB is full of interesting scales from all over the world)
What is the point of stating that though? It's pretty hard to know ahead of time and talent is rarely worth more than sheer effort.
Not only that but I would say technical lead of a software team that revolutionizes the industry requires many other skills besides writing the best code. In fact, people skills probably are far more important.
That, contrary to positions that portray programming as a skill only valuable to those who would be able to use it to become the equivalent of an exceptional artist, that the number of people who could derive benefits (professional/financial -- not to consider other personal benefits that might accrue) from learning programming is quite large.
> It's pretty hard to know ahead of time and talent is rarely worth more than sheer effort.
I'm not sure that there is a clear line between talent for a particular task and the ability to maintain concentrated effort directed at it, nor do I think that it is easy to pull apart the effects of each. But, sure, I'd agree that you can't know who can benefit the most from lots of things (programming included) ahead of them trying it.
Which is another strike, IMO, against those who would dismiss efforts at universalizing exposure.
That's not the point of the article--it's not that there aren't some people with insane intrinsic talent, it's just that the majority of people fall on the below-average - average - above average distribution, and that you can create plenty of great stuff right in the middle.
The other point is that the "concert pianist" and "master painter" are damaging stereotypes for the development industry--almost no one is Mozart, and the persistent and toxic idea that every programmer needs to be Mozart prevents good people from feeling good about their work.
Additionally, he makes "good programming" a bit more nuanced. "Programming" isn't a monolith that you can either be good at or bad at--it's composed of many subcomponents that you can have various competencies in without suddenly passing a magical line from good to bad. I think the argument is quite a sane one--the stereotypes that people fall back on are just that: an attempt to reduce a complex set of conditions into a simple binary.
This is a critical subtlety to this discussion that is never mentioned as evidenced by the comments in this thread. Just like "piano player" is a continuum, so is programmer. I will never be able to work at Google because I lack the requisite skill set in the same way I'll never play Carnegie Hall because I'm not good enough. But that doesn't mean I can't provide quite a lot of value to businesses who don't require the kind of talent Google does.
I like to think of ecosystems in discussions like this. Yes, the Google/Carnegie Hall ecosystem requires the talents of rockstars. But the places I work are a totally different ecosystem and require a different type of individual.
I think the main frustration is that the required minimum level for developing software in a team really is comparable with the skills required for working in a studio orchestra - not only at google but actually for working on any system above a certain size. Maybe not world class, but certainly rather good. In both cases, some "intrinsic" talent is probably required, and it helps to have a rock star or two to really get the team/orchestra to deliver.
One other factor is that most systems and programs of a certain size are actually quite hard to work with - the "average" may not be enough, driving costs and unnecessary complexity until the system spirals into it's own collapse and eventual replacement.
One problem is that while anyone can tell if someone is any good at playing the piano, it will probably take 6 month or more to discover who is 30x more productive at developing and maintaining software, or who will in fact destroy more value than they contribute in the long run.
It's safe to say that developing software requires more than the average level of "talent" that is available in the population, and possibly also among the profession.
>> I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter."
So learning to code is equivalent to being a master painter or concert pianist? Which both are amongst the top 1% of their field probably.
Anyone can learn how to paint or play a piano, the level they'll achieve won't be the same everyone, but anyone can do it, just like anyone can learn how to code.
I can't speak for the painting side of things, but no, not everyone can learn how to play a piano. For one thing, left-hand / right-hand independence isn't a universal trait, and isn't something that can always be "learned" (there's a reason why chord / melody books are so popular). Finger independence is even trickier. Sight reading, relative (or even perfect) pitch -- these are _talents_ that make a good performance possible that often can't be learned by those who lack the talent.
Designing algorithms, debugging, interfacing with hardware, finding efficiency -- the myriad of things that go with programming, these things can be done by a layperson the same way a wealthy hobbyist pianist can plunk out "Music Box Dancer" on their $10,000 grand piano -- but will they be done well? Will the hobbyist pianist give a great performance? They might be happy with it, and that's fine. But will they get to Carnegie Hall? No?
I'm not saying the hobbyist pianist shouldn't try any more than I'd say anyone who wants to write a program shouldn't try -- but the article suggests there's no real benefit to "talent" and that's just silly. There _are_ rockstar programmers, and we should acknowledge them, just as there are great concert pianists. And everyone should be encouraged to try both piano and programming. But not everyone will be successful at either or both of them.
It's probably also true that not anyone can become a truly capable finish carpenter, but we don't build an elaborate mythology around why that is, and we assume that most people have a pretty good shot at it, if that's what they want to do.
Yes, probably anyone can become a master painter, but for a person with a disposition and love to painting it's easier to start and to keep going. For someone who loathes painting, it's massively, prohibitively harder.
Success in any craft (and science) in 5% talent / luck and 90% hard work. But the love to the craft / science makes exerting this effort massively more rewarding. I don't think that training oneself to be a master is not attainable for someone who does not have a burning passion for this specific mastery. For instance, a mastery of programming might be a gateway to other things, for which the passion is burning.
The number of things for which ability to code is now a gateway is growing, be it financial modeling, computational chemistry, linguistics, etc.
Also, there's mastery and there is peak achievement. Everyone (except severely mentally disabled) can be taught writing skills and write nice, clean, well-organized texts. But probably not everyone can become Hemingway or Borges or Nabokov.
Equally, everyone can be taught to write nice, clean, well-organized code. But probably not everyone can be a superstar like Knuth or Norvig or Carmack.
So I'd reserve the word "talent" for the highest achievers. Talent is not required to be a decent programmer.
I normally stay out of these debates, but as a teacher, you may be in a unique situation to appreciate this view point: How about "learn to code"=="learn to play the piano" == "learn to paint"?
I don't think that you learn to code "just in case." I learned because it let me automate some things and later, let me make my own games. It turned out I've been good enough to get paid for my level of "talent," but I'd still be happy I learned, besides the joy of the mental excercises, I've also been able to automate alot of (ussually self imposed) challenges in my life.
I also learned to play the piano in my teens. I'm a sucky digital-artist as well. It was obvious I'd never be a concert pianist or master painter or even get paid for either. It baffles me that people can go through life without being able to play an instroment or paint, but I didn't learn "just in case"; I've been making use of both for my own enjoyment and unpaid sharing with others.
I think a great many of your students who lack talent will get great use out of the ability to automate processes on a computer and maybe gain life long enjoyment, even if they don't have the presupposed talent.
I think there is a matter of degrees and a matter of return on marginal "talent" for lack of a better word. Being a concert pianist (or Lady Gaga or Floyd MayWeather) is competitive in such a way that the return on being the 1-in-a-thousand is way better than 1-in-ten. Way better.
Most things are not like that. In fact very few programmers even pursue that. Most science is not even like that. If you are a zoologist studying marsupial reproduction, you are not in a winner take all contest, you are in a 'do thew job' situation. You don't have thousands of eager marsupial reproduction researchers biting at your heels. There are plenty of marsupials to go around.
Most things are like this. Even pianists once needed to attain an achievable level of mastery in order to be pianists professionally and entertain aristocrats before the invention of the Zune. The availability of aristocrats did fluctuate and so did (I imagine) their interest in music, but it's not the same as trying to be the best pianist on earth.
The realistic version of this is that output, especially creative output varies by person. Also throughout ones life, by context (is this fun for me today?) and lots of other ways.
Some kids hat math. Some of them wouldn't if the teacher or method was different. Most can do pretty well.
Exactly this (though OP's article touches on this too). All the BS about category theory, lambdas calculus, and "logic" aside, DHH was absolutely right when he said building large software systems is much closer to writing a novel than anything science or math. Because of this inherent creative art nature, programming often depends on divine inspiration (for lack of a better term) - sometimes you sit down, and immediately see how all the workflows and data-structures, sometimes you can beat you head against a screen for months and wind up refactoring half of it.
In my opinion, the best way to tell if you are cut out to be a great programmer or not is whether you can finish and publish a project or not. Sorting algos, typing speed, functional programming, monads, es7-await, and all that jazz that interviewers like to look for can all be learned (and, comparatively, they are easy to learn), and even if you learn them, it won't make you a good programmer if you can't build extremely complex and yet detailed systems in your head.
A more accurate analogy would be "anyone can learn the piano well enough to play in a bar and entertain patrons", i.e. not in the 1% of piano players, but you are good enough to be effective at a job.
Also, I felt that the point of the article isn't that anyone can code, it's that we are discouraging people who COULD have coded.
There's a huge range of skill between "concert pianist" and "no good at piano." That's kind of the point of the speech, I think
There are hundreds of pianists with a very high degree of skill, but that are not concert pianists. Many are essentially freelancers and take gigs as they come-- choir accompanist, pit orchestra pianist, keyboardist in a band, resident organist in a church... etc.. Many of those pianists are quite skilled and talented, even if they are nowhere near skilled and talented enough to be a reknowned "concert pianist" like Murray Perahia, Emanuel Ax, Alicia de Larrocha, Mituko Uchida, etc..
The excessive focus on the idea of a "concert pianist" talent leads to this situation where the day to day programmers aren't getting the credit they deserve. For more on the under-appreciated musician analogy: watch the movie Waiting for Guffman and pay attention to the musicians. The dialog in the movie basically never acknowledges them. They're completely taken for granted by the other characters, but they are impeccable-- easily the most professional performers in the production. There's one point where one is playing the trumpet and timpani at the same time. I think that's the idea-- solid, productive programmers not being recognized for their talent, because they're compared to some incredibly high ideal.
Though there's also this dunning-kruger thing where lots of mediocre programmers think they are way more skilled than they actually are either because they're the best programmer in their little bubble, because they're a devout adherent to some specific coding religion, but haven't ever really been measured against an objective standard. Specifically because there are so many words wasted on "rock stars" and "ninjas" as well as blubbers and someone's personal experience with some horrible developer whose incompetence caused so many problems, etc...
> I will certainly never say "anyone can learn how to code" any more than I'd say "anyone can become a concert pianist" or "anyone can become a master painter."
I disagree respectfully with that statement. First you devote a lot of your time to try to teach peeps about CS and I think that's great. But I'd argue that music and coding, to your comparison are essentially languages (former is a language of rhythm and melody and wielded by a physical/electronic instrument, latter is a language of algorithm and logic and dictated by a PC) and learning them is akin to language acquisition.
So IMHO, there is an illusion of talent when you have native speakers who can speak with perfect accent, grammar and fluidity; just like there are "native" musicians who have perfect pitch, can transcribe and improvise on the fly, play with speed/style. Because they have internalized the grammar, and that language's vocabulary and phrasing are by definition the native's first nature.
But non-native speakers can learn a foreign language albeit very painfully, perhaps with an accent and pauses that they'll never get rid of. But they can still express themselves successfully. Put it simply, I believe anyone can be taught the basic's of web development/CRUD, OOP, basic flow-control just most people can be taught how to play "Chopsticks" or conversational English. The programming equivalent of writing "The Great Gatsby" or composing a sonata, I'll concede that to the real talented.
>Put it simply, I believe anyone can be taught the basic's of web development/CRUD, OOP, basic flow-control just most people can be taught how to play "Chopsticks" or conversational English.
Someone who can do web dev/CRUD is employable, someone who can only play chopsticks is not (in fact you wouldn't even listen to them for free).
Even if I agreed with everything else you wrote you brought no reason why people should be able to acquire more proficiency in programming than they can acquire in piano playing.
Also, I think learning how to program/paint/play is nothing like natural language acquisition, from an evolutionary point of view there is no reason why this should be.
I believe that, in theory, 99% of everyone can learn to code. However, some people will take prohibitively long to do so. These people may have other talents, but they will struggle in learning how to code and probably only achieve minimal success.
Of course, that's using a completely vague and arbitrary assessment of successful coding. I teach an intro coding course for non-majors at the undergraduate level. So my numbers are based on the performance assessment we use.
to be a great concert pianist it is 5% talent 95% hard hard work...
If you dont train your fingers every day and if you dont play for at least 1 hour everyday since your 10 or younger you wont become a great concert pianist...
you can say the same for coding.
it is 5% talent but the rest is coding coding coding coding...
If you have talent the start will be easier but at some point talent wont help anymore just studying and trying.
So, one of the best illustrations of how talent works is in football placekickers. To make it in the NFL, you have to be able to reliably kick a field goal at X yards. X goes up every so often. Some athletes can do it, some can't. I read a story once about a guy trying to level up his skills to NFL-level. He spent weeks out on the field practicing his kick. He could hit the goal, but not reliably. One yard closer, and every kick sailed right in.
One of his buddies, a minor league baseball pitcher, went out with him one day, asked to give it a shot. On his very first try, he kicked it right in. A pitcher.
To be great, it requires getting out on the frontier of human ability. That frontier often looks very, very weird. One seemingly small additional challenge turns you into a puddle of mush. Getting there requires hard hard work.
But excelling over everyone else who also put in that hard work requires talent, and it's generally a binary proposition. Until it isn't. Once Roger Bannister broke the 4 minute mile, floods of athletes started doing it.
Then the frontier goes somewhere else, the talent required to get there is increased. But one can only put so many hours of their day into an activity. So when you're talking about greatness, talent ultimately matters more than hard work. One should ideally find out as quickly as possible whether one has the talent to make it out to the frontier of human ability. So they don't waste lots of time doing something they can never find greatness doing. The aforementioned aspiring placekicker? Gave it up. Now he's a successful author, real estate investor and football coach.
I agree that practice is integral to being successful as a concert pianist (I am a pianist also so I didn't make the comparison casually), but to give a truly inspiring performance (and not just be a human player-piano) requires much more than just memorisation and repetition. It requires creativity and instinct as much as skill.
Programming is similar. If you were to boil programming down to simply "engineer a list of commands to make the computer do X" then sure, most people can do it, with practice and documentation. But to make the computer do X with efficiency, or to make the computer do X in a new and novel way -- or even discover that X is the wrong way to go and the computer really should be doing Y -- also requires creativity and instinct, just like giving a great performance at the piano.
"Greatness does not come from programming by rote."
The thing about "coding" is that it's simply the means, not the end. The configurations you can program a Turing complete device with proper hardware into are, for practical purposes, boundless. Being a concert pianist can intersect with many fields as well (acoustics and music theory alone can get quite deep), but ultimately the immediate direction is much more narrow.
In fact, I would argue that just "coding coding coding coding" won't get you all that far alone. There's plenty of "reading reading reading reading" so you can actually have the skills and knowledge to write what's intended, and then there's all that lesser visible knowledge out there that is just as crucial, but hidden in (relatively) obscure references or papers - unless you intend on reinventing lots of square wheels.
It's not inaccurate or offensive to say that some people are more naturally gifted in some areas than other people. It's certainly possible that with 10,000 hours of practice the average person could become competent at just about anything, but there will be outliers on both ends of that spectrum.
I disagree with this. I think natural talent is what allows you to pass the "filters" from better tutors, people which just wont train you unless "you've got it"
Good programming is an art. The same can be said for good photos, or good works or fiction, or great compositions.
The reality is that most computer programs don't need to be good. In most cases they don't even need to be efficient. They just need to work. Even then, they usually just need to work for a short time because of the ephemeral world of software development we live in.
There are some really incredible engineers out there. When I look at their code I'm often in awe. "Why didn't I think about that," is what I think to myself. Or someone is using some bizarre function or mathematics that I don't understand to achieve something with an efficiency I couldn't ever come close to in my own code.
Most people who make a living writing code are just writing the same things over and over again for different employers. There's no elegance in what they do. There's no art. I make websites, apps, and simple programs for automation. Sometimes the end result looks pretty, but if I'm being honest with myself the code is very… meh. Anyone could do it.
Living in the Bay Area I can safely say it's mostly a dog and pony show. There are a few people doing something really interesting, actually pushing the limits of technology. Most of us are not those people. Most of us (myself included) are writing garbage for silly products that people use to distract themselves. It's fun, but not really challenging. Most of the people I work with have no idea what hard work actually is.
Working in the Bay Area is the easiest thing I've ever done. Honestly, I didn't realize life could be so easy. Learn how to sell yourself, make something appear on an iPad, and people want to pay you $100k/yr. Sometimes I feel like a thief, but everyone around me is doing the same thing.
If the approach to encouragement is to require artisinal comparisons for success, then you're alienating many right out of the gate.
Most kids loathe piano lessons. But they can still be 10-100X better at it than anyone here and not need to stroke their egos by calling themselves artists.
"In a fixed mindset, people believe their basic qualities, like their intelligence or talent, are simply fixed traits. They spend their time documenting their intelligence or talent instead of developing them. They also believe that talent alone creates success—without effort. They’re wrong."
I've been at this twenty years, and I have no doubt that most people can learn to do it, and some people are just radically better at it. I'm not sure why those should be either mutually exclusive or controversial points of view. Where the passion part comes in is that most people, the vast majority I would think, just don't want to do this for a living and never will.
We're a little like medical doctors in that respect. A lot of people would like to have an MD's paycheck but very few would actually enjoy doing what an MD does for a living. Another analogy, and one of my favorites, is to watchmaking. Watchmakers take great pride in the incredibly close work they do, and again while it may be work many could learn to do, it is work that few would want to do. I think this is very true of programming. Most people find it horribly tedious and boring, and don't see the creative aspects of it at all.
The last thing I'd note is that the focused act of programming is becoming a smaller and smaller part of the gig. To be a full-stack developer these days requires so much more than the ability to create a working program. The big picture is very big, it takes many years to get a really sound grasp of it, and you have to be motivated in the first place. Passion, again.
> To be a full-stack developer these days requires so much more than the ability to create a working program. The big picture is very big, it takes many years to get a really sound grasp of it
This is a major point that tends to be overlooked by a lot of people.
There's a big difference between just "coding" something to make a little feature work, and actually building an architecture that can support many kinds of behaviors now and in the future.
Many people can't seem to make the jump to the "bigger picture" version of programming
> Many people can't seem to make the jump to the "bigger picture" version of programming
TBH I am not sure there is even a viable "smaller picture" version of programming. Sure you can write some simple scripts and compile some C++ or Java or run some python. But I have to think 99.99% of what you could actually make a living doing would require knowing a stack at least from the database up to the browser or desktop.
You can know the stack but then write raw code with nested if statements and for loops to just implement the current requirements to the letter. As soon as a small change is introduced to the requirements, you're screwed.
> The last thing I'd note is that the focused act of programming is becoming a smaller and smaller part of the gig.
Unfortunately it took over 5 years as an engineer to learn that being able to communicate effectively is the single most important task of any job. If you've ever struggled to explain yourself to people then take some writing or speaking classes from a local college, sign up for a Dale Carnegie course, join Toastmasters for a couple years. Your career will thank you for it.
>>Part of the problem there is the lack of a way to even measure coding ability. "We are infants in figuring out how to measure our ability to produce software", he said. What are our metrics? Lines of code—what does that measure? Story points? "What even is a story point?", he wondered.
Indeed, what is programming talent? What is a 'good' programmer? What is a 10x rock star? These notions are similarly ill defined. I can think of at least 3 formulations of 'talent':
1. A developer who can craft an exquisite solution to a problem using the patterns of the domain and/or the idioms of the language.
2. A developer who puts in Heroic efforts to produce a lot of code in a short amount of timing, to meet business objectives.
3. A developer who is 'smart and gets things done'.
One can poke holes into any of these formulations; is the exquisite solution delivered in a reasonable amount of time? Is the quickly delivered code maintainable and extensible or a maintenance nightmare? Does the smart and get things done guy leave a spaghetti trail in his wake?
In the end, I think we've all noticed that some people tend to simply accomplish more, with less issues and drama than others. Is this real? Or simply navel gazing? I tend to think it's real.
I suspect it will always be a largely subjective measure mostly determined by the respect or accolades of one's peers or the satisfaction of one's target audience/customers.
I think StackExchange's "reputation" system is probably the most accurate discrete measure available.
Reputation on SE is very, very dependent on the amount of time you put in and your choice of which questions to answer. It's also somewhat zero-sum in a crowded field, as you need attention to get upvotes.
(I should know, I'm one of the 50 people on electronics.stackexchange with more than 10k rep, and no formal qualifications in electronics)
For me, StackExchange's 'reputation' is inversely correlated with that.
Don't want to attack the contributors, but honestly, the higher levels of reputation just either show me that he either has too much free time outside of work (valid, but doubtful) or they spend work time answering questions, which for me goes against the 10x productivity programmer mantra.
I think StackExchange's "reputation" system is probably the most accurate discrete measure available
I would be very hesitant to rely on any metrics coming out of SE. Consider their great programming survey this year, they say the average age of a programmer is 29. The US Department of Labor says it's 49.
There are a vast number of people out there, well over 90% of the programming industry I'll wager, who come into work at 9am, do good, solid work all day, on applications that run the real world, then go home at 5pm and get on with their lives, who never interact with SE et al at all.
>I would be very hesitant to rely on any metrics coming out of SE. Consider their great programming survey this year, they say the average age of a programmer is 29. The US Department of Labor says it's 49.
That doesn't mean they're both wrong. The two are just comparing different things. The SE programming survey included 157 countries, not just the US. It also doesn't only include full-time professional developers. 13.6% of respondents classified themselves as "Student". Only 66.3% of respondents listed themselves as "Employed full-time"
Aside from the significant asymmetry of the distribution (of course) there's the spikes where people push themselves to hit a mark (i.e. 3:59 vs 4:00).
Programming is full of weird incentives that will distort themselves in any measure -- e.g. if A gets his/her work done in 0:20 and B in 7:30 and A then goofs off or helps other coders, the measured productivity difference might not be huge. Since most people who code are having their behavior distorted by measurement that's a big issue.
From experience -- the incentives against outperforming expectations are huge -- demonstrate you're 3x as productive as the guy next to you and from now on you have 3x the workload for 1.1x the pay. In practice what happens inisthe better coders pad their estimates and get trusted with tough problems rather than time-consuming problems.
1.5 Million position job gap? Really? I hate when people throw the us labor stats numbers around like that.
Uh, hu, I wish these statistics would be backed up in a more through manner. Like maybe forcing companies to disclose how many applicants they get for a position and why they were rejected.
I say this because, I recently interviewed for a position doing some pretty low level work, where apparently there were a 100+ applicants (or so the hiring manager said). But it was believable because the job was posted on linked-in, and linked in reported that 34 people applied for the job.
So, a lot of people applied for the job, were they qualified? Well, considering I know two people with skillsets that are compatible with the position, and both are unemployed and live within 5 miles of the position, I would really like to see this kind of data industry wide.
AKA, assign each candidate a number (only disclosed to the candidate), and then publicly post the number, and the reason for disqualification. Maybe if someone can figure out how, disclose the skills the candidate says they posses without directly correlating them to the candidates public profiles.
That would give us an idea of where the skills gaps are, or even if they are real. Rejecting a bunch of candidates because "they don't fit the culture", or they don't have 5 years experience with CMVC, or perforce or some other tool not directly related to the specific job requirements needs to be public information. Or for that matter, that someone thinks they will ask for more money than the position pays, without making them the offer.
It's not that programming skill (whatever that is) is bimodal, it's the effectiveness of the engineer in a typical development scenario. That stems at least partly from the fact that programming is hardly ever a one-person endeavor, contrary to running.
Since scaling a team increases friction and overhead, a small number of highly skilled engineers can be absurdly more effective than a set of teams, which also makes them more valuable, but not necessarily as extreme as in sports. Add preferential attachment to the equation (good engineers try to work with other good engineers / hire only top talent), and the U-curve starts to make sense IMHO.
It also doesn't count for how low skill (inherent, trained, etc.) can have a negative impact on a project by incurring vast amounts of technical debt that will have to be repaid that outweigh any positive contributions made.
I haven't really seen any evidence that this is true.
The talent myth as Adrian describes it is one of stereotyping: there's no data to accurately measure skill in programming so we simplify things in our heads and believe you're either talented or not. This myth appears to directly support your claim: untalented individuals are a cost burden on the enterprise. If this were true there would be far fewer enterprises to match the number of actually talented programmers: that is to say you and I are not likely one of them.
The reality I've experienced suggests that deliberate process correlates strongly to quality. In the absence of true talent we can still write great software by leveraging processes and tools to wrangle complexity and manage defects. We see this in plenty of engineering disciplines. Why is software so special?
>The reality I've experienced suggests that deliberate process correlates strongly to quality. In the absence of true talent we can still write great software by leveraging processes and tools to wrangle complexity and manage defects. We see this in plenty of engineering disciplines. Why is software so special?
Because of the entry level.
Think of this joke: What do you call the guy who graduates from medical school as the bottom of his class? Doctor.
The point is that even though there is a worst, they still have to have gotten so far. Even the worst engineer had to do good enough to become an engineer, which is a far greater test of skill than what I've seen in some interviews, especially when those hiring are not technically experienced.
I think many who call this a myth happen to have rarely come across these people in technical roles. At worst they may have interviewed a few, but they were quickly cast aside. They've never met a person who managed to get into a senior position as a cargo cult programmer who can't explain even the basics of the frameworks they are using.
The point Adrian was trying to drive home is that for any quantifiable skill we can measure we find that there is a bell-curve across candidates. The over-whelming majority of people are average in every human endeavor that we can accurately measure in this way. The theory goes that software development is not different.
If we assume that the bell-curve is likely to exist then it's probable that only a handful of people exist in this current generation who are at the far-end of the curve. If the success or failure of an organization involved in developing software is dependent on the talent of its people alone then I'd rather speculate on futures.
If there is such a thing as the Mozart-of-programming you can't expect to hire a whole team of Mozarts. Any policy to only hire the best available programmers is upholding a culture of egotism and hubris. It's just not probable.
I've only seen this belief propagated by people who are more concerned with being better than everyone else. It's convenient that their finger only seems to point outwards. I don't like working with people whose sole talent is the ability to recognize the lack thereof in everyone else but themselves.
WRT mythology, one important takeaway about the "1.5 million programmer job shortage" is the management declaring the shortage isn't looking for programmers, or white male programmers, or "rockstar ninja real programmers" but ivy league grads willing to sit thru 8 hour logic puzzle and coding interviews about linear algebra to work for $7.25/hr for minimum 80 hours per week in an open office packed in like sardines while people "work" by playing foozball for 60 hours per week next to you in one of the most expensive cities in the world for next to no stock options in a field rife with ageism where their career will be shorter than a typical NFL quarterback. But other than that, no problemo.
In reality there's no shortage, and isn't going to be one, outside a couple industries in NYC and SV.
That means we need to be doing something to get more people into our industry.
Why? What's in it for me?
The EU has published similar numbers, 1.2 million in 2018—three years
I am a first-year CS student in Denmark and I hope you don't succeed in getting more people into the industry to fill those jobs before I graduate.
The lack of (talented) programmers is going to put young CS/CE grads in an advantageous position both in term of salary and job opportunities. I am happy employers are having a hard time finding people to fill those jobs. That makes life easier and safer for me.
The people screaming for more programmers here in Denmark are people in the government and Dansk Industri (lobby group representing bigger Danish corporations). The government cares about something they call "Denmark's global competitiveness" and the lobbyists in Dansk Industri want to flood the market so they can lower programmers' salaries. I don't care about the former line of buzzwords and the later is a hostile action taken against me as a programmer.
Don't get me wrong. I care about our industry. I will contribute to open source in the summer leave and I am involved in organizing some monthly meetups. But in the end of the day I also want a job.
This is such a backward view of how the programming job market works that I am not really sure how to approach it.
You can't really have too many programmers. Every field needs some degree of computer automation. As more gets automated innovations are made that will show us how to automate something that hasn't been automated in other fields. Until everything in every field is automated more programmers create more opportunity for even more programmers.
I also think it is messed up to be selfish enough to hope your whole country suffers until you can secure a job.
The importance of talent is often overstated, but it's not a myth.
The years I spent trying to do software development were like beating my head against the wall. Everyone seemed to be much better than me, and it led me to give up after a few years of starting and stopping. If I couldn't even manage to make a simple application, what was the point when so many people made one every day?
So I gave up and focused on other interests, like writing and art. Writing has served me well, but doesn't interest me enough to get much written. I'm just bad at visual art, no matter how much I practice and study. Fractal art is about all I can do[1].
Then I picked up a MIDI keyboard, a DAW (first LMMS, then Studio One) and had fun making music immediately. Haven't been able to stop since. Now I'm rediscovering my interest in A/V engineering. As you can imagine, knowing a little programming helps a lot with both of these things, and that's how I found an interest in writing code.
Most of the code I wrote even before finding a need is solid, efficient, and secure. But that's because I'm so bad at it that I have to be careful. If I don't write clean, efficient code, I won't be able to understand it well enough to fix it when something goes wrong.
I think we would be better off encouraging people to try many different hobbies rather than pushing them into something they have no affinity for. Then, when something clicks, show them how programming can make it better.
This is all anecdotal but learning to program is (IMO) somewhat like math in that it is virtually impossible to learn it while not feeling confused and lost because there's a lot you have to internalize (and often this includes multiple concepts sort of all at once) before everything clicks and makes sense.
Talent is a thing, surely, but IMO the primary "talent" when it comes to learning to code is having the mindset where being lost isn't a problem for you. Some people hate this feeling of not intuitively knowing what is going on (possibly for an extended period of time!) while others embrace it, the latter tend to be the ones who end up excelling at programming (and/or math).
"Most of the code I wrote even before finding a need is solid, efficient, and secure. But that's because I'm so bad at it that I have to be careful. If I don't write clean, efficient code, I won't be able to understand it well enough to fix it when something goes wrong."
If your code is good it is because you are a good programmer. Full stop. Not being able to understand and fix your own code if you aren't writing it cleanly (and as simply as possible while doing the job) is universal.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan
I am well aware that there is a considerable range of ability among those who program professionally, but it never occurred to me to think of the distribution as being bimodal. I have also noticed a preference among programmers (or rather, more likely, a vocal minority) for reducing all issues to simplistic dichotomies (e.g. the methodology wars.) Perhaps this is just another straw man, distracting from the real issues of how to raise levels of performance incrementally and generally?
Well, I just disagree. I've been doing this professionally for over 10 years and some people are bad to okay at it, and others are good to excellent. If there isn't some deep-seated reason why people fall into one group or the other, if it's just practice or whatever, fine. I don't know what the explanation is. And I don't assume it's impossible to move from one group to the other, far from it. But I would say the bi-modal thing seems roughly correct.
Huh? You say you disagree, but then state that programmers can range from bad to okay to good to excellent? That isn't bimodal, and is precisely the authors point?
The story mentioning the woman who did not consider herself a "real programmer" is obviously disturbing. But that is not the consequence of believing in a bi-modal distribution of programming talent. Rather, it is the consequence of believing in a bi-modal distribution AND believing that gender also fits that distribution.
The bi-modal distribution of talent is not a myth nor is it intrinsically harmful. However, it can be extremely harmful when misinterpreted to mean gender, race, etc. The author is subtly conflating the two and in the process doing more harm than good. This does not help women, minorities or other under represented groups.
It seems plausible to me that the distribution of innate programming ability is a bell curve, but the distribution of programming effectiveness is bimodal. The missing ingredient of course is experience and education. It's similar to an athletic skill, such as the high jump. If you plotted the maximum height that a random assortment of individuals could jump, the resulting graph would be bimodal: the top clump would be those who can do the Fosbury flop and the bottom clump would be everyone else. The innate ability to jump follows a bell curve distribution, but unless you know that trick, you'll end up on the lower clump.
It's quite simple...
There are people who have a knack/drive for understanding the world/universe and its many functions. People who care to understand the root mechanism as opposed to speculating about how the tree and leaves form. This is the base talent behind good software engineers who become great through experience and challenges. If you -truly- understand something, you are good at communicating it in many ways and capable of expressing it in a 'language'. What came first? Language or understanding. What do a lot of institutions teach? Programming. What don't companies want to invest in : Understanding....Mind the gap.
You may be good at a language and still not have any good ideas to express;Programmer
A lot of people fail to see this and go on with arbitrary measures of what makes a good software engineer. Oh nos', you don't know how to craft the perfect general expression for this. Oh nos', your Translation look-a-side buffer calculation was off... And so on.
The typical interview centers on how well someone programs. People write long articles which stirs people into a frenzy and much is lost in the discourse. Mindless interview structures are administered which tests people on their ability to work through leaf problems.
Tress of horrible construction are made and root analyzers are called in to save the day. Since there aren't many who fully understand root construction, such talent is hardly ever understood for its value : Modern software engineering at your alphabet soup of companies.
And here we are. Much will never change because there are few actually looking at the root issues.
Few actually care to. It's all about the leaves and low hanging fruit.
Some people can refactor a messy chunk of code into something more organized. Some can create a rough sketch of a large system that is well-organized and loosely-coupled, others can optimize an algorithm for efficiency.
Some can write code that is easy to read and understand. And some can write code that is extremely abstract and expressive.
It's rare to find all of these skills in one person. Depending on the project goal, some of the above are crucial and some are nice to have.
All of the above can be learned, and for some experience is the best teacher, while for others a CS background helps a lot.
Last summer I went into a job interview and said "I'm not really a programmer."
The next week I was hired to do Ruby on Rails work for a freelance contract. (I'd been lured to the interview to talk about data analysis with R but they needed a Rails person more.) Clearly the interviewers thought my level of experience was fine.
I've got a PhD in mathematics and am no stranger to technical fields. I can't believe I was "that woman" who said she wasn't a programmer. It really does happen. My G-d, I'm a cliche.
Very nice article. It reminds me to this quote from "Hackers and Painters" by Paul Graham.
"In general, people outside some very demanding field don't realize the extent to
which success depends on constant (though often unconscious) effort. For
example, most people seem to consider the ability to draw as some kind of
innate quality, like being tall. In fact, most people who "can draw" like drawing,
and have spent many hours doing it; that's why they're good at it."
Programming benefits from dogged perseverance. If you have lots this trait, it can overcome other shortcomings.
It also benefits from being thorough and detailed: analyzing all the cases that may occur, forming all the conceivable hypotheses and so on.
It doesn't matter if it takes you five hours of hacking on something to finally see a solution that some brilliant programmer came to in 45 minutes of hacking.
Maybe it was luck; his or her brain generated some spontaneous idea which revealed some aspect on the problem resulting in a breakthrough, while you were methodically working through various hypotheses (including the boring ones).
Brilliance will lose in the long run to dogged perseverance and thoroughness.
Brilliance has an advantage in dealing with badly structured programs; the brilliant mind has a great memory and can simultaneously hold a lot of the program in consideration: for example, to visualize a complicated run-time interaction between numerous scattered pieces of code. The more brilliant mind can handle a larger instance of this sort of thing than a less brilliant mind. But there is a limitation on it. It's kind of like being muscular. It's impressive that you can bench 300 pounds, but it's useless in the big picture where we might need to lift 30,000 pounds. And where we therefore use a machine to do it, and that machine can be easily operated by a "90 pound weakling".
We can erase the advantage of the brilliant mind by not structuring the code such that only the most brilliant minds can visualize how some scenario arises in order to identify a problem. And we can also use tools: tool to help us visualize, analyze, validate, and so on.
Where we ultimately need brilliance is in forming ideas. Someone who comes up with great product ideas (and ones that sell, too) cannot be replaced by a machine, or by someone who just has perseverance and thoroughness in the face of details.
What I find fascinating is the ability of software developers to work against their own interest.
> The US Bureau of Labor Statistics estimates that by 2020 there will be a 1.5 million programming job gap, which means there will be that many jobs unfilled. That's in five years. The EU has published similar numbers, 1.2 million in 2018—three years. That means we need to be doing something to get more people into our industry.
There you have it. That's how many of us are thinking, while at the same time we suffer from ageism, wage-fixing, working overtime and being seriously underpaid in general for the value that we provide to our employers. How can we be so stupid as to care about programming jobs being filled? Is it any wonder that we end up being abused?
A typical useful idiot grade remark by the speaker. Actually we as software devs have to ensure that the supply of talent in our field is somewhat balanced to our interests to protect our financial positions and prospects from degrading due to the influx of new devs on the job market.
I think Jacob is engaging in sloppy thinking. Like everything relating to biology (in particular, human beings) there are two components. One is nature. One is nurture. Every single activity in life will require both components to come together. Everyone will have different aspects and amounts of these components.
It reminds me of Jane Elliot's teachings. It's not that 'there
is no difference'. There is definitely a difference. The truth is that difference is good. It's good that we have both good and bad programmers. It's good that some people are rockstars, and others have to struggle. Diversity is good.
The problem is not "the 10x myth". I don't think its a myth. I think there are 10x althletes, 10x doctors, 10x engineers. Pick any field and the spread between the best and worst performers will be enormous.
The real problem is some people think that because they are a better programmer (or a better pianist, or athlete, or engineer, or doctor) they are better people. That their life somehow has greater meaning. This is the myth that needs to be debunked. Being a 10x programmer does not make you a better person. In ANY way, what-so-ever. It just makes you a better programmer.
What makes you a better person, in my opinion, is how compassionate you are, how much you care for the less fortunate and how much you work to make this world a better place for everyone.
Sadly I would say the same applies to money, many high earners seem to think that it makes them better people, when often it seems to be the opposite.
I also think there are 10x environments that allow you to thrive as a programmer, as I have personally found my workplace to allow me to be around 4-5 times more productive on a quiet day when I am allowed to focus, over a normal day with constant interruptions. Add in some people you could learn from and I could easily see 10x productivity gains from one environment to the next.
It is a myth though, regardless of whether you, personally, believe it to be or not. It's based almost entirely on a very old study, conducted in a very limited environment, cited by Fred Brooks in “The Mythical Man Month” and then taken further and further out of context. As Jacob points out in his talk, we don’t really have any compelling reason to believe we know how to measure programming productivity, so we don’t have good data. In the absence of good data, we have to assume that the null hypothesis is that programming is like literally every other skill out there. And, no, there are not ”10x atheletes”, we know what the skill distribution is for atheletes, there is a tremendous amount of publicly available statistical data available on athletes, and, again, as Jacob points out in his talk, their skills fall on a normal distribution just like every other kind of skill out there.
So, there are outliers, which is what I think you mean by "10x atheletes", but those outliers are just that: outliers. And we do not have good metrics for determining who they are in the software industry, currently.
The problem about 10x myth seems to be the comparison point that each of us is making: is it the best vs worst, best vs average, or a binary threshold between the best vs everyone else? And then even defining the "worst" seems to be very hard for a field like programming.
And a bit of a tangent, I don't disagree with your last statement in the specific. But in principle, that's a very dangerous statement to make: if you're living within the moral constraint of a society, there really should NOT be any criteria that define a human to be a better or worse person.
I think we probably agree more than disagree, but I do disagree with your last sentence. This right and wrong is above the 'moral constraint of a society'. A whole society can believe something is right, and another thing is wrong, but that does not make them right and wrong. For example, a majority of a society may believe that honour killings are right. But they are not.
It's not some moral relativism that depends on the context. Right and wrong are absolutes, and can be objectively appraised. And here's the metric: Suffering. Right actions are those actions that lead to a reduction in the suffering of living things. Both in others and in ourselves. Wrong actions are those actions that lead to an increase in suffering in ourselves or others.
This is how we can appraise our actions. This is totally off topic, and I'm definitely showing my Buddhist beliefs, but I think the attitude shown by your last sentence is held by a lot of people in society. And I think it is also muddled thinking. This kind of 'moral relativity' is actually a slippery slope and has been used to justify all manner of human atrocities through history.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make art less intimidating for newcomers.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make music less intimidating for newcomers.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make writing less intimidating for newcomers.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make football less intimidating for newcomers.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make architecture less intimidating for newcomers.
There's nothing wrong with a skill that takes time and effort to become good at, and there's no reason to cater to people who aren't at least novices. Well, not unless you're trying to artificially inflate the labor pool so you can pay programmers less.
I know I'm not the only one old enough to remember that we already tried to apply this argument in the late 90s?
That left us with countless completely incompetent programmers, most of whom left the industry after Y2K and the burst of the bubble. Those who stuck around now largely make up the bulk unemployed IT workers whining about how there can not possibly be any shortage because nobody wants to hire them.
We've already put the talentless to work in massive numbers, and not only did we as an industry pay the price, it didn't do the por sods much good either.
Also, all of these arguments about mediocre programmes, 10x programmers, gender based discrimination etcetera only serves to distract and intimidate, because they have nothing to do with the fundamental question. Nobody is arguing that a having a talent for something is the only thing that matters when it comes to how good a programmer you become, or that it has anything to do with gender.
Bringing it up only serves to pre-emptively make anybody trying to make a counterargument look like an arrogant, sexist douche. My instinct tells me that people trying to make a point that way already know they're wrong.
One the main issues with such collectivist argument is that programming is more than solely 'programming'.
A great developer innovates, organizes, leads and motivates other programmers in a way others are not able to do. Kaplan-Moss is a perfect example of it.
For example, maybe, it's true that anyone is able to build a CRUD website.
However, maybe, not everyone is able to start and manage an open-source project.
Not really, programming is 'solely' programming, as in the ability to generate code that is reliable, readable, well organized, efficient, etc... .
What you are talking about is programmers that in addition to their technical skills have also leadership and management capabilities, which make them absolutely invaluable in a company, but not necessarily more skilled or "talented" at programming than others.
In this topic: people demonstrate they don't know what "bimodal" means. A normal distribution of programming talent doesn't preclude the existence of "10x" programmers.
There are different types of skills -- and if you can combine them, you are the 10 to 100x times person;
Understand the business problem, and then have enough tech skill to solve it and you can move mountains. Most managers know neither the business domain, nor the technology, which makes it even harder.
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.
Indeed, I hope you feel overwhelmed by the sort of guilt that only purchasing a subscription can dispel. Inspiring such feelings was my motivation for posting the link in the first place :)
Is there anything that can be done to make LWN.net look a bit nicer? There's often very good and interesting content on there - for which I'm grateful! - but the presentation really is rather a throwback to the pre-CSS days.
There's a new site design in the works; subscribers can play with it now. It improves the situation in a lot of ways, especially on small screens. But the text-centric nature of the site is not going to change.
What is programming talent? There are many different jobs where one writes code, but they're very different. A very big part of a developer's success depends on whether and how they can navigate the business domain they're in.
> This belief that programming ability fits into a bi-modal distribution (i.e. U-shaped) is both "dangerous and a myth". This myth sets up a world where you can only program if you are a rock star or a ninja. It is actively harmful in that is keeping people from learning programming, driving people out of programming, and it is preventing "most of the growth and the improvement we'd like to see", he said to a big round of applause.
How does he know that bi-modality is not true? These are questions we should ask and study rather than things we should just assume are myths. Ignorance is not the answer.
Especially if one don't even define what is the exact quantity measured. IQ is a normal distribution by definition, (IQ-100)^(1/3) is "bi-modal", it's just a simple transformation and both quantity correlates (supposedly) with the vague term "intelligence".
The question is not in bi-modality though, it's whether you can go from the left side to the right or the middle over time or you should have been born as a rock star.
> The truth is that programming isn't a passion or a talent, it is just a bunch of skills that can be learned
I think people who makes these statements are usually misguided by their lack of perspective: talented people have a hard time understanding how someone else can't do it when "it's so easy"
One example of this is Bill Gates driving Microsoft to commoditize programming ("I can do it, it's easy, therefore anybody should be able to do it").
Programming talent isn't bimodal, in fact it isn't a question of traditional talent at all.
There are only two levels of programming ability: "Bad" and "Good Enough". In all but the rarest of edge cases, everything else is a matter of preference. You think that someone's code is elegant, simple, clean, optimized, etc? That's great, but only other programmers might care about those things. The only question that the majority of people care about is, "Does it work?"
Obviously code can be written so poorly that it causes noticeable performance problems, or doesn't work at a scale past the initial requirements. But that falls under the "Does it work?" question. Basically if I'm using it and it isn't annoyingly slow, whoever wrote it was "Good Enough". I don't care if they were a l33t 10X rock star ninja or some guy who just finished a "$language For Dummies" book.
It is genuinely cool to see code that is well designed and well written. And doing that consistently does require the innate talent of a special mind. But let's not confuse elegance with doing the job. Doing the day in day out work of programming is like being a journalist: the most important thing is getting the facts straight, not writing something pretty. The truly talented can do it with the rhetorical flourish of a poet, which is awesome, but not required.
All that most people ask of code is that it's good enough to do whatever it's supposed to do. If we want to turn it into a poetry contest then it's definitely a bimodal distribution, and most of us will end up on the wrong end of the curve.
Your argument falls apart completely when you take the long term lifecycle of the code into account. Which is exactly why we keep having these discussions.
And by the time we pay the price everybody cares. Of course, by then it's way too late to start caring about such esoteric programmer obsessions as elegant, simple, clean, and most of all: open to change.
Yes, all people ask is code that is good enough to do whatever it's supposed to do. They just have no fucking clue of what it is that the code is supposed to be able to do besides satisfying their short term needs.
This speaks nothing about maintainability or extensibility, which can add great value to a product in the long term. These factors aren't a matter of style or aesthetics, and they go beyond simply getting code to work.
> It is genuinely cool to see code that is well designed and well written. And doing that consistently does require the innate talent of a special mind.
And we've immediately returned to the bimodal myth.
I would say it comes from someone who (1) cares about the quality of their work, (2) has a sense of what constitutes good or bad code (a sense most often acquired through experience), and (3) has the foresight (also usually acquired through experience) to make early design decisions that pay off later. None of this requires an innate genius.
"Formal logical proofs, and therefore programs – formal logical proofs that particular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it"
I see that section 4 contains a reference to another study offering an alternative explanation for the 'double hump': if a teacher sets the pace by the progress of the fastest learners, you can end up with a group that kept up and a group that was left behind early and so never learned much. I guess this is more likely to happen if you have several students, rather than one or two at most, who already have had some exposure to the material, and that this is more likely in programming than in, for example, actuarial mathematics.
Well I won't be linking that anymore. Anyways, I was really more interested in the little narrative observation above than the numerical results of the study.
The quote reminded me of a study I read about a year ago, in which the problem-solving skills of toddlers and chimps were compared. The toddlers generally did better, except in one regard: when shown how to do something, but with some pretty obviously irrelevant steps included, the chimps were quicker and more likely to drop the pointless steps. At the time, I thought that might be explained by a human predisposition to pay attention to authority, but, in the light of that quote, perhaps it is (also) a predisposition to formal / abstract thinking? Furthermore (to make a wild speculative leap) perhaps it is this predisposition that is actually behind the phenomena that Chomsky thinks are evidence for an innate universal grammar?
>But that would mean that programming skill is somehow distributed on a U-shaped curve. Most people are at one end or the other, which doesn't make much sense.
But this is exactly the case! It's why Fizz Buzz exists: to determine if you're on the left leg or the right of the U-curve. (Or similar curve wherein people "suck at programming" or that they "rock at programming", without leaving any room for those in between. Everyone is either an amazing programmer or "a worthless use of a seat" [in a programming job]).
Why can't we accept that this is the nature of progrmaming?
Jobs wasn't a coder, and was on the left side of the U. Wozniak was and was on the right side.
Brian Chesky (airbnb co-founder) can't code, is on the left side of the U. Nathan Blecharczyk (another airbnb co-founder) can.
There is nothing exceptional about this distribution. You can have a ton of vision and product input, design input (as Brian did) without being on the right side of the U as a coder yourself.
On the other hand, perhaps all coders on the right side of the U are all awesome, which is why they command six figure salaries sooner out of college than other professions take to get a terminal degree in their field.
FizzBuzz is a test, not the results. If you can point to a study that has administered it to a well selected group representative of professional software engineers that displays a bi-modal distribution, then I'll accept that as evidence. Until then, it's just anecdotal data about the quality of a self-selected group attempting to get a well paid job.
Fizz Buzz is a pass/fail test that wouldn't even exist if the pool being tested weren't bimodal. Why would anyone administer the Fizz Buzz test to a normal distribution of programming skills, for example? (I mean https://www.google.com/search?q=normal+distribution)
It would make no sense - below what part of the normal curve of programmers would you put someone who failed at FizzBuzz (cannot code it)?
In my interpretation it's because programming skill doesn't follow a normal (bell-shaped) distribution, but is bimodal. Which is why Fizz Buzz exists, to tell you quickly which pool (left or right) your candidate is from.
Either that or we have a completely different interpretation of why Fizz Buzz exists or what it means. Why do you think it exists?
IMO it's not a talent. It's a result of thousands of hours of work. I learned programming at 12 years. I programmed a lot. I didn't have a computer and I was programming in sheets of paper (computer was in school and I didn't always had access to it). I wrote by own object-oriented GUI library in sheets of paper and that library was never written in computer but it was in my head and I learned a lot while thinking about it and its design. There was time when I was spending 10-12 hours programming or reading programming books.
I wouldn't call myself talented programmer. I spent a lot of time to learn how to write good enough code and be productive.
What I had is a passion to program. I never programmed because I had to force myself. I enjoyed it. It's a beautiful art. That beauty forced by to program. And I still find that beauty in programs.
Unfortunately I don't know how to learn others to enjoy programming. I saw a lot of programmers and most of them didn't really like their job, they just did it because they went to CS faculty after school and programming is paid well enough.
Based on what I've seen, anyone can write code, just as anyone can learn math or write a story. Further, anyone who devotes time and effort to writing code (or doing math or writing a story), who immerses themselves in it, who learns and practices, can write code well. Thing is, most people aren't motivated to do everything well. People find enjoyment in different ways; some through working with their hands, some through solving puzzles, some through talking to people. I wouldn't say this is purely natural (I didn't discover programming until later in life thus I'm nowhere near how skilled I'd be if I started at 10, although once I knew what it was I knew I would enjoy it), but I wouldn't say it's purely up to environment either. Anecdote: I introduced a friend of mine to programming recently. He can do it, and he's not bad at all, but he'd much rather be face-to-face with someone than staring at a screen for hours.
So, anyone can become a good programmer, but most won't want to be.
Yet more programmer/tech industry denigration propped up by completely unproven assertions.
Firstly most of this is based on the idea that as a programmer you are only either great or shit, and that this is somehow a problem of the industry rather than just being something entirely human and normal in ANY WALK OF LIFE (the best and the rest).
Secondly, there's this awful assertion that this purported industry problem has resulted in a less diverse industry. (What does that even mean, other ethnicities & women can't handle pressure as well as white men?)
But imagine how frustrating it must be to be a woman with a decade of experience
and have someone assume that she doesn't know what she is talking about.
^ This just comes out of nowhere, someone assuming that a woman programmer "doesn't know what she is talking about" is not related to any point he's made previously.
It's not out of nowhere. The context is very clear in the video, and in the article it's just a few paragraphs earlier:
> When we see someone who does not look like one of those three men, we assume they are not a real programmer, he said. Almost all of the women he knows in the industry have a story about someone assuming they aren't a programmer. He talked to multiple women attending PyCon 2015 who were asked which guy they are there with—the only reason they would come is because their partner, the man, is the programmer. "If you're a dude, has anyone ever asked you that?"
The original version of the "10x" idea didn't require the productivity distribution to be bimodal - it could be a bell curve or skewed bell curve with high variance. I think it's contextual as well - if you're working on a project that's just at the edge of your present abilities, your productivity is going to be pretty marginal compared to someone who's done it before and has strong aptitude at it.
I think it's silly to simply sort programmers into two buckets.
It does make a lot of sense though to try to attract and retain good programmers though - having a programmer who's at the 75th percentile of productivity instead of the 50th percentile is going to give you a big boost in productivity if productivity is high variance. It also makes sense to try to match programmers to projects that they have good aptitude and motivation for.
I took one programming class my Freshman year in college, and dropped Computer Science as my major because even though it was an Intro to Programming class, I felt like I was the only person in the computer lab that was actually programming for the first time.
It infuriated me working for half a day on an assignment and then watching these other kids come into the lab, knock out the assignment in 20 minutes and laugh about how easy the assignment was.
After college, I taught myself how to build websites, which led to javascript, then PHP, then databases. Teaching myself on real world projects was enjoyable because there was no comparison to anyone next to me, it was just me trying to figure out how to get something to work. And when it worked, that felt great, not horrible because it took me 10 times as long as someone else.
One thing missing from the whole bimodal vs. normal distribution debate is: what is the population that you use as a base?
If you take all humans as the base, the vast majority for any skill that isn't nearly universal is clustered at the zero. Of the 9 billion people on earth, nearly nobody can write programs to any meaningful degree, or play the piano to any meaningful degree, or build a telescope, or a wrist watch, or whatever.
So I'd assume that programming ability distribution looks a bit like a normal distribution centered at zero, and cut off at zero (no values for skills less than zero).
Which, ironically, makes basically everybody who can write a single line of code "above average". Which doesn't make them rock star programmers at all.
I think in small organization you might need a lot of talent, but once organizations (or projects) get bigger, you need process over talent and that, well, also means good management. There are things you can do with a small group and things you can only do with a bigger group. I guess Django is at a point where it's big enough that it can take advantage also from the less talented coders. Maybe, and I am wild guessing here, part of the issue comes when startups grow and still look for the 0.1% talents, when at that size that can easily live with the 40-50%.
The illusion of a U-shaped talent curve is just that - an illusion. Specifically, it's an illusion brought on by selection bias. We see more of the people beyond a particular point in the curve. Maybe we even see them because they're exponentially more productive than people further back, but at most that means the work product distribution is bimodal. The skill or talent distributions surely have a bump or two here and there, but remain basically normal.
After a few decades programming professionally I have yet to encounter the idea of a U shaped talent curve where most people are either geniuses or useless. Does anyone actually think that?
Nor have I been on any team since arriving to California that had a majority of young white men. That actors portraying Mark Zuckerberg look like him is hardly surprising or a good scientific sample. I didn't read past that section.
I think there is a question of progression through your career as well. For talented programmers, (I believe) it is less likely to feel 'stuck' at some point. Over the years, they can handle increasingly more complex challenges with same relative ease. Others have to do significantly more efforts to handle abstractions well enough to ensure 'cruising' along.
Saying that there is a programming skill is a little like saying that someone has a "sports" skill. There are many different skills of programming that are very different, and except some basic "can do fizzbuzz" level, there are miles apart skillsets, where you can be great in one context but bad in another. a few examples
- fast hacking / programming contest / hackathon skills - write correct solution fast, not caring about how the code looks or be read later. (great for contests, bad if you do it also at work, code is read more than written bla bla)
- software engineering / organization skills - for 99% of enterprise software development, and large chunk of CRUD based web development, you need to be organized, and clean, there are no "algorithms" to implement, you just need to have good concept of MVC, separation of concerns, write methods that do just one thing, meaningful variable names. in these settings, most of the code you write is simpler than even a fizzbuzz, you get data from a form, validate it, save it, do some business logic, generate reports, that's it. This needs a whole lot different skillset than what a "top talent X10 programmer" would offer. This needs planning, design, patience, not trying to change the world, being OK with writing Java annotations, being just a regular professional software grunt.
- Library and API designers - there is a great skillset of writing a library that has self explanatory interface, good documentation, and is just a fun to use. People who know how to build a DSL or an API that makes sense, is a whole different skillset than the above 2, and a fizzbuzz test will not be the one that will let that diamond shine in an interview.
Programming is not just one skillset just like "music" or "sports" or "writing" is not a single skillset.
You can be a great comic actor but a lousy dramatic one, you can be a great sports writer but never be able to get a novel published. you can be a great golf player but never be able to win your 10 year old kid playing soccer no matter what you try.
Perhaps FizzBuzz is the common denominator, e.g. you can say that if someone can't play a C major chord on a piano, they are not going to be a pro musician, but anything beyond that, anything that tries to test "programming skill" beyond that level is not far from auditioning a violinist on a chelo just because both have strings.
I'd say that the 'talent' of programming comes from the tenacity to handle all kinds of bullshit and be able to adapt and survive in this environment. Just setting up a Python environment on Windows is a nightmare, and most people will just give up. Second part of the talent is the experience of how to handle or avoid all the bullshit and get the work done.
The creativity part of programming requires a good sense of usability, a good sense of how to organize things nicely and those things require some sort talent yes.
The same applies to language and grammatics. One thing is to write a phrase well, other thing is to transmit the right emotions with the phrase you write.
by definition, most of us working in this crowded industry are mediocrity. And even if somebody is a very talented programmer (say like me :) the system will make sure that it doesn't matter in the end.
(until of course, one is so "talented" that s/he made onto the barge as a foreman or better - owns the barge, though it usually requires completely different from programming talents)
Poor analogy follows:
Programming ability is like chess ability. The skill lay on a regular distribution, but the game that 1900 players play (top 5%) is much different than the mean (~1400).
the comments on this are a fascinating read. who knew programmers had such a deep belief that their ability is rooted in almost magical notions of talent, art, creativity and is not just another skill you can learn.
it is definitely a satisfying notion to think of your activity as a consequence of a god given gift, rather than just a job, but as engineers i think we should do better than relying on anecdotes and beliefs to understand what it is we are doing it.
I think one difference between this lady who built a complex system and "a programmer" is that the typical professional programmer works on a legacy system.
The set of people who believe programming ability is bimodal and the set of people who believe they're in the higher of the two modes is pretty much identical.
maybe she said she "was not really a programmer" because she didn't want to be associated with one (consciously or not). I have heard that sometimes women view programming as a low-status job i.e. akin to labor.
My experience totally contradicts this. I am a biz guy but I have been privileged to work with a handful (literally, about 5) developers who are not just 10x better than average but 50x or 100x better. Its like denying Black Swans - rare is different from non-existant.
I won't argue against that but I have a problem with biz guys who try to evaluate what kind of a developer someone is.
I'll not judge that you don't have knowledge about the field or about code, so don't take this personally, but in my experience I've seen far too often some biz guys praise developers who are sloppy, developers who code unmaintainable stuff and which biz guys loves because they're always delivering, much of the time ahead of the schedule.
But when you tried to bring a team around what they built it was almost always code that was not able to be maintained by a team. When the original developer was long gone you had a team of 5 pretty good developers trying to figure what the hell is happening with that code, and biz guys demanding to change the team because the 50x developer had done so much in less time.
As I said, I'm not saying this personally as I don't know your background but if we are throwing anecdotes that's one I have from the top of my head, some praised hyper-productive coders are that way because they take shortcuts and some don't even know they've done it. I just think that the occurrence of really good and smart and productive developers is so low that I've yet to remember more than one that I've worked with in the last 10 years, I've worked with great people but I can remember only one who I can put in the bucket with a "great soft and hard skills, hyper productive and smart" label.
My wife and I volunteer teaching "programming" to my son's second grade class once a week. It's actually a mixed first/second grade room so half the kids in the class are first graders. I've been teaching them writing simple algorithms and games in scratch (scratch.mit.edu) and studio.code.org.
These kids are young enough that almost nobody had any exposure to "coding" or algorithmic thinking before this. It's about 30 kids. Here's what I've observed (Yes it's anecdata... but I'm reporting my own impressions here):
There are about 6 kids who're pretty quick on most of the assignments... evenly divided between 3 girls and 3 boys... then there's about 15-20 kids who are more or less similar in aptitude. The top 5-6 programming kids are also the kids who I feel have the most advanced verbal skills (just from speaking with them). I've been told by the class teacher that two of these kids are advanced math learners but the others are good students but not advanced beyond grade level.
The more surprising part is the bulge of 15-20 students in the middle. That's a far bigger number than what I expected who regularly complete challenges correctly and within the time given. Many of these kids are not particularly top level math students. Most seem to have good verbal skills but nothing exceptional. Most surprisingly, many of these kids are first graders. Once I saw this in the first few classes, I significantly raised the level of challenges I was giving them. And they kept working them out. It's fair to say that I was pleasantly surprised.
Yes it's not a particularly strong scientific study but I'm here to say that there's absolutely no way you can convince me that Programming ability is some genetic trait with a bimodal distribution... at least not in the absence of hard scientific data. The one study that has polluted our discourse for many years (because Jeff Atwood trumpeted it on his blog) was retracted in dramatic fashion by it's own lead author:
And to complete my story - Yes, there are 2 kids who don't particularly enjoy this class at all. They do seem to be behind the rest of the class in general scholastic aptitude though by no means "stupid"... my wife spent an extra hour with them separately and they thrived under a higher level of direct attention. There are a handful of others who end up doing their challenges slower than others. One of the most amazing and heartening things I've seen is that the kids who finish the challenges are spontaneously going to the kids who haven't and have been helping them out. And in the end, each and every kid has finished all the challenges we've given them
There's a lot of scenarios that could produce what we witness, and eliminating one doesn't prove which of the others it is.
It could be the case that programming talent is bi-modal or multimodal, but each mode is itself a normal distribution. There would be a "talent" involved, but it would still produce a normal distribution once you cut the bottom off. This is suggested by such things as the bimodal distribution on the handful of peer-reviewed papers that at least opened the question about whether incoming freshman could be sorted into "those who could get it" and "those who can't" buckets by a simple multiple choice question at the beginning of the test. (I do not claim they have solved the problem, but it is an interesting data point. This is that paper that was extremely widely misunderstood by professional programmers as being a test that required the students to guess in advance how things like "equality" worked in programming languages, when in fact it wasn't about being "right" about programming languages but about being able to form a consistent theory about how such things might work.)
It may be the case that talent is single-mode normally distributed, but there's also a threshold necessary to function, which can be at any arbitrary point along the curve; I'd suggest evidence would suggest it's certainly above the average as with all due respect to my fellow humans it does not strike me as the case that more than half of the human race can simply become professional programmers. (This is less elitist than it sounds, because in many cases supply & demand is such that only the best can become professionals anyhow, and that's not just "NBA basketball players", it's even things like music composers or painters. If you are a 50%-th percentile composer, do not try to make a career out of it. I say this as one who has faced down this choice personally.) The resulting truncated-normal distribution of talent in the professional space would have a lot of people piled up on the bottom, being just barely able to cross over the talent bar, and then a long-tail effect where extremes would be more likely than you'd naively expect. Further, courtesy of the Central Limit Theorum, as this initially non-normal distribution of talent went through the usual random vagueries of life and professional career, it would be the case that the curve overall would become more normal, but would be quite likely to retain the longer tail and never be quite normal. This is suggested by the fact that this rather does sound like the programming world we live in.
Further if we're going to go all social-engineering on the question, I'm not particularly interested in telling people pretty lies to make them feel good, or worse, make ourselves feel good about how good a person we are, while sucking them in to a career that does not suit them. If talent exists and matters, then it behooves us to say so and give people the ability to examine themselves with eyes open and ask if this is the right thing for them, or if they should pursue another career which they may find more satisfying. There is, of course, a lot of room for "average programmers", almost by definition, and "average programmer" already likely entails "above average talent when the whole population is considered".
The problem with the argument that "Programming skill can't be bimodal because that would be elitist and make me feel bad about myself being an elitist" is that there's a lot of evidence that programming skill is bimodal. Look at fizzbuzz as an obvious, if not entirely complete, example.
Would it make us all feel better if programming skill weren't bimodal? Sure. But a roomful of people clapping at that proposition doesn't make it true.
I think you can break it down further into four groups. People who, when presented with FizzBuzz on their first day of learning programming would:
(1) Not even try, because it's "too confusing." (c. 90% of the population).
(2) Be able to finish only with significant assistance from others.
(3) Be able to finish on their own through trial and error.
(4) Finish quickly, and wonder why they were asked to solve such a boring problem.
Note that programming ability is a function of interest in the subject as well as intelligence. I'd say that most people who go into programming are somewhere between groups 2 and 3, while most who end up being successful at it in the long term are somewhere between groups 3 and 4.
Group 1 will never be programmers, group 2 is where I fell the first time I tried it. Group 3 probably have some training and group 4 probably have some programming related experience, or maybe they are superheroes. At any rate, anyone in groups 2-4 can become excellent programmers if they apply themselves and get the help they need. They can be plotted on a programmer competency bell-curve. Group 1 are the people who will never learn to code because they refuse to try. They probably make up the first hump of the perceived bi-modal competency graph. But they were never really in the running at all.
I can think of at least 2 people in my 30-person cohort in college who did not know how to code, and would fall in the first hump of a bi-modal competency graph, despite having passed 2 years of programming courses.
So my theory is that the second hump is a normal bell curve, and the first hump is people who won't try.
so lets say if i solve fizzbuzz quickly iam clever.
i have solved it but in a shitty confusing way but i have solved it.
but someone who solves it through trial and error and learns new stuff about what can go wrong and how it works is not so clever?
coding is always trail and error because you cant think of all the possibilities and through error you learn and become better so yeah give me more of 3 then of 4
> Look at fizzbuzz as an obvious, if not entirely complete, example.
I am not entirely convinced this is not partially a resume screening and talent pipeline problem. Has anyone ever given Fizzbuzz problems to everyone who applied to a position? If you haven't, have you ever considered that your screening process may be broken in the sense that you are passing too many liars who then bomb the Fizzbuzz portion, but who bump competent people off the stack entirely so you never test them?
I find this idea that there are lots of fake programmers kind of nuts.
Presumably, when you do a resume sift, you look for people with either a qualification or work experience. Either they somehow faked it through those, or your test is bad. Fizzbuzz actually tests if you know what % does. Is that critical knowledge for a webdev?
> I find this idea that there are lots of fake programmers kind of nuts.
I don't know about "lots", but there are definitely people out there who claim to be programmers but lack the basic competencies they claim. I've encountered several.
A couple of years ago, I was part of a battery of interviews for a candidate who claimed a Master's in CS. Their resume said they had done advanced work in parallelization of video compression. I asked them about it - I wanted to know how they had handled synchronization and locking.
The candidate looked at me blankly for a couple of seconds. Then they began, haltingly, to talk about web sessions and logging.
We didn't hire the person, but there was definitely some bullshit along the way...
I don't think there are "lots", but I think there are enough to distort the view of the labor pool. Additionally, there is the issue of these fakers staying in the pool much longer and spraying their resumes out more often further distorting the view.
As for how they get through the screen, I think they just blatantly lie on their resume hoping to get a company that doesn't do its due diligence in determining if the stated experience is real.
I've interviewed people for programming positions with work experience who had trouble articulating solutions to very simple problems. I don't know that I'd call them "fake programmers", but "bad programmers who lack the ability to reason about code and instead rely on StackOverflow answers to provide solutions to the problems they're faced with" are all over the industry.
The world of actual programmers is NOT filled with fake programmers. The world of people actively applying for advertised programming positions IS dominated by fake programmers. That's why FizzBuzz is an effective screen.
As to your last question, a "webdev" who doesn't understand integer modulus is a fake programmer. Is it critical? I suppose it's not if your grid is never wider than one column and you never want to alternatively style rows in a list or table.
We give fizzbuzz style tests to all our candidates. Most fail, but it's not an indicator of experience at all. Some of the quickest to pass just got out of GA and never worked in the industry before. It really tests aptitude at a specific type of problem. Because of this it does not make or break the interview. We also look at their portfolio/code samples as well. After interviewing many candidates I've found the one's who pass our fizzbuzz tests also have much better code.
Because of this I'm convinced that aptitude and passion are significantly important to the ability to program. Just grinding your way through CS classes will not a programmer make.
I should add we let the candidates use google, so even if they don't know modulus or whatever, they still can prove their ability to look up things.
> Because of this it does not make or break the interview.
You mean that you continue the interview process for a coding position with someone who failed FizzBuzz algorithmically/structurally (not for a trivial syntax error)?
At a prior game company we gave what I felt was a FizzBuzz-level task on paper: in C, given a string of characters representing a hex number, return the long it represents. (basically, write strtol(input, NULL, 16); without using strtol)
I was appalled at the number of people who couldn't come close (not subtle bugs or mis-handling case issues, but rather: show someone else their code and have that person guess what function the person was trying to write).
When the Fizzbuzz blog post(s) came out, representing a much simpler problem, I couldn't believe that someone would bother to shower and leave the house to interview for a programming position and be unable to do Fizzbuzz. So I gave Fizzbuzz to a few candidates, often in a joking sort of way (so as to not offend any qualified candidates). Results were predictably shocking and dismaying. It's a problem simple enough that you either can do it or not; there's precious little middle ground. (As other posters mention, these are the people that interview over and over, so hopefully the actual employed population of programmers is overwhelmingly able to do it.)
In which case it becomes bimodal in the sense there are people who consider themselves programmers but who do not meet enough skill to be considered one.
As someone that works in the game industry and interacts with programmers and artists (not only graphical art, I am also counting here writing, music, etc...) daily it is BLARINGLY OBVIOUS that both skills require certain brain patterns.
Although there are some rare people that are both great programmers and great artists at the same time, usually the person is a programmer, or an artist, they might know skills of the other side (example: I am a programmer, but I have a design bachelor's degree, and know how to use lots of artists tools and correct art made by others, but I would never call myself a good artist) but they are clearly one thing, not two.
This usually is also reflected in their behaviour, for example programmers frequently act in more logical or common sense manners (or sometimes in a extreme logical manner that go against common sense, but still logical), and can be viewer in some ways as "boring", and tend to prefer things rooted in reality.
The artists are not uncommon to do things that are unexpected, or to like outlandish stuff, for example when playing an RPG with extensive character customization you will usually see the programmers min/maxing the stats or trying to go for realistic stats, and outfit the character in realistic clothes, or the best equipment in terms of stats. Now when you look at an artist character they frequently are different, for example you might see a orc magician, or a space marine with low accuracy stats, high charisma and that paints his armour pink with yellow dots.
Then when we get to real work, the need for talent is obvious: Innate programmers frequently make boring art, IF they can make good art at all. Innate artists sometimes can make some code, but usually it is badly engineered code (prone to bugs and breaking), and that is, sometimes, most artists can't code at all, you can try to teach them all you want, and they just don't understand, even those that might grasp the syntax still end never getting past basic logic.
Of course, sometimes you find some people that are exceptions, for example the Falanghe brothers:
Felipe Falanghe is the creator of KSP, he, and his twin brother, studied with me at university, they are clearly artists, during university their highest grades were always in pure art related classes, they could make amazing drawings, and they had a band and were both fairly good singers and guitar players, yet both of them decided to learn Flash and Unity coding, and although their code was frequently broken, hard to read, confusing and had huge amount of memory leaks, clearly it was possible to do something with it, since KSP is a success, and Felipe Falanghe started coding it by himself in Unity.
Isn't this akin to claiming that drawing is bimodal because most people can't draft a portrait in an interview. Or, worse, that there is an element of gender influence in ability because, "otherwise there would be more female programmers."
I certainly agree that there is likely a gulf between good and great. Probably another above it. I'm curious to know what actual evidence there is.
Drawing seems like a great analogy because it definitely is also bimodal. Some people can draft a portrait in an interview and those people would be the ones you would want to hire to be your portrait artists.
This cuts to two important points. First, you will be hiring as if it was bimodal.
The second point, though, is more whether or not it actually is bimodal, or it is just taught into a bimodal distribution? That is, is it intrinsically this way, or is that a biproduct of how society values and teaches it?
Yes, I will be hiring bimodal and it's worked very well for me. Whenever I relax my process and hire someone I'm not sure is a great developer I always regret it later when they can't perform and their work brings down others. The more experience I have, the more I stick to working with the best people I can. There are just too many ways to fail and having a team of experts is the best mitigation you can have against it.
Apologies on possible tone misunderstanding. I did not mean that point one was bad or at all incorrect. Just stating my follow on point that there is open research as to how something like that came to be.
More, I think something like this can not really be attacked at the point where we are looking at people being hired for a job. The causes for a bimodal distribution in ability will likely stem much farther back than that and will have to be addressed as such.
Consider the mythical patient that says it hurts to bend their knee. First, yeah, stop bending your knee in a way that hurts it. Second, lets find out why you can't bend your knee that way.
I agree that any talent shortage is likely to be an upstream problem from hiring.
I don't agree that eliminating a bimodal model is desirable though. We don't really need more people in the middle of the talent trough because they don't actually add much value and can often detract value (in my experience). Successful programming is the grappling with immense complexity. You really only want the best and brightest doing it. As long as the people with the desire and capability are being given the opportunity to enter the field, I think we've succeeded. Trying to lower the bar or get people who wouldn't excel into development would be a mistake though.
I didn't realize I put forth that the bimodal should be eliminated. Just that I don't think it should be taken as a natural fact. It may be that eliminating it is meaningless. It may be that keeping it is meaningless.
Consider, do you really care about having the best and brightest doing something. Or just getting the best results. Odds are high that those align at least somewhat with each other. I don't know if it is a foregone conclusion, though. Study will show.
If you have experience that a normal distribution brings down the top end, I'd be interested in seeing it. If it is just a gut feeling, it is something that can be tested. If it can't be tested...
I wish I had the resources to formally test the hypothesis but alas I don't. However anecdotal my experience is, it has been consistent and enough that I'm not willing to risk my career hiring anyone other than the best I can find. It's actually a lot easier to hire mediocre developers so I wish that produced great results. It hasn't for me though.
I want to be clear that I am not asking you to formally test anything. And, I would extend "you" to the entire industry, at some level. I do not expect companies to try and tease out the reasons for distribution in workplace for most things. Affirmative action not withstanding.
What I do applaud, is research to into the problem. Which begins, largely, but asking the question.
Most people can't draft a portrait in an interview for a programming job. Most people interviewed as portrait artists would, as would quite a lot of people in related trades (such as graphic designers).
The fact that programming interviewers give this kind of test and it's widely failed shows what a bad state objective evaluation of programmers is in.
> If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again. That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.
In my experience people really are either amazing or terrible and those that are amazing are super passionate about programming, think about it and study it all the time...
I don't really understand the argument as to why this isn't desirable. Just like any difficult task, performing well is going to take a lot of practice and dedication to keep your skills fresh.
99% of the software that actually matters - medical devices, air traffic control, credit card processing, phone switches, you name it - is written by people who work 9-5 and don't think about their jobs outside work. If all the websites programmed by "rock stars" shutdown overnight, the next week everyone would have forgotten they ever existed.
Having worked on several systems like that, I can say there are definitely passionate developers behind any serious code. An "old guy" I know that has lead development on several extremely high volume payment processing systems has the most extensive personal CS library I've ever seen.
No one is writing high performance code without deep knowledge of what they're doing.
That is true. But also noone is writing critical systems staying up all night drinking Red Bull. Look at other engineering disciplines. Where are the bridge and dam building rockstars? Where are the nuclear power ninjas?
I wonder what "rock stars" are going to do when they discover other uses for their time, hobbies, families, sports, travel and so on. Resign?
I think you're talking about two different things:
1. People that are dedicated to their craft, write A LOT of code and self-study in their free time.
2. Red bull drinking Valley stereotypes.
People from camp 1 don't live up to the stereotype of the "rock star" but definitely work way more than 9-5. Where work is defined as studying languages, domain specific knowledge, low-level code...
People from camp 1 also do not generally curate a public profile, since they generally come from traditional engineering cultures where judgements are made based on past experience and ability to reason about complex systems during interviews than on flashy portfolios and pop quizzes.
I don't think it is much of a stretch to assert that the vast majority of code in the world that accomplishes important business goals is not "high performance" and in most cases doesn't need to be "high performance". So this is not really addressing the main point of the comment it is replying to.
> medical devices, air traffic control, credit card processing, phone switches
Those are all high performance areas of coding that would require great skill to execute correctly. Aside from medical devices, they all require a lot of concurrency and real-time processing in the case of air traffic control and phone switches. They are practically the definition of high performance programming.
No, if there is a definition of "high performance" in colloquial use, it's number crunching on a supercomputer e.g. weather forecasting and so on. Guess what, thats a very important application of computing, and once again, rock stars are notable only for their absence.
I think someone can be very passionate about coding and still only do it 9-5. Being passionate about your job, loving what you are doing, taking pride in it, and committing to building an excellent product doesn't mean you can't ever do anything else.
Not really. Matlab, WindRiver RTOS, LabView, Visual Studio, Intellij, and a whole bunch of other critical tools in that area were not written by hobbyists.
> 99% of the software that actually matters - medical devices, air traffic control, credit card processing, phone switches, you name it - is written by people who work 9-5 and don't think about their jobs outside work.
I don't believe that, you have some evidence for this claim?
I do, but it is all personal anecdotes from having worked for a large defense contractor for almost ten years and a small one for three. Nobody had "passion". Nobody was doing anything in their spare time programming-related beyond some trivial toying around. Then again, the vast majority were Gen-Xers and the stereotypical "work to live" attitude associated with that generation was very visible.
As an aside, I would like to note the difference as I see it between passion and work ethic. There were people who put long hours in, but they did so because there was work that needed doing. In fact, the people who put in the longest hours generally had the least proportion of technical work. They weren't there because they "loved programming"; they were there because they felt they needed to be to help the program and company go forward.
> 99% of the software that actually matters - medical devices, air traffic control, credit card processing, phone switches, you name it - is written by people who work 9-5 and don't think about their jobs outside work.
I don't think anecdotal experience from 2 jobs is a sufficient sample size to make such strong broad statements about a slew of industries.
>In my experience people really are either amazing or terrible and those that are amazing are super passionate about programming, think about it and study it all the time...
I enjoy programming but I don't spend every waking second thinking about it. If that makes me a terrible programmer then thats fine with me. I'd rather be happy than be killing myself working 16 hours a day like some people like to glorify.
The people doing it 16 hours a day aren't killing themselves though, they do it because they love it (some of them obviously). In fact they would be killing themselves to not be thinking about programming 16 hours a day.
Anyone who has dealt with Django should believe his claim to being mediocre. ;)
Actually I think this is a good article which makes some good points, but I think it misses another harmful myth; that people are one thing all the time.
It substitutes the idea that people are either good or bad programmers with good, bad or mediocre.
But in reality, one person is not always good or bad or mediocre all the time. Someone might write brilliant code today on this project the are passionate about, but write shitty code next quarter on a project that doesn't have their interest. Or while they are distracted because something came up outside of work. Or because they are writing in a new, unfamiliar language and they don't realize the code is bad. Or any number of other reasons.
Human beings are fluid things. Over time someone may develop an average quality of output, but that's only going to be something that comes about over time. And ultimately, I think it's somewhat meaningless. Since the average is not what you care about in any given case, and may or may not be applicable to whatever new thing comes down the line.
Plus, as the article points out; how do you really define good or bad? Number of errors that get caught by unit testing on first submission or number of errors which don't get caught until the code is already in production?
There is a myth, but the myth propels reality. Take this line in the article as a reason:
> That leads people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.
This attitude will create ninjas/rockstars/whatever, even if the original notion isn't true. Folks who spend every waking hour thinking about and learning about something are going to be better than the folks who don't do that level of effort.
I agree that programming skill is going to shape itself into a bell curve, but I would also argue that a bump exists in the 3rd or 4th standard deviation, with all the folks who've been driven (for good or bad reasons) to eat/drink/breathe programming.
The thrust of the article is that it's okay to be mediocre, and I agree, but I don't think it's healthy to be satisfied with where you are in any skill-based craft. It's more healthy to be okay that you're not already better (I'm not a rockstar yet), but being okay with not getting better is a toxic thought.
This attitude will create ninjas/rockstars/whatever, even if the original notion isn't true. Folks who spend every waking hour thinking about and learning about something are going to be better than the folks who don't do that level of effort.
It will create people who believe themselves to be something special, sure, but that's all you can say for certain. Where are the results that prove it is deteministic? For every startup full of rockstars that succeeds, there are 1000 who worked just as hard and sunk without a trace.
One can say, with absolute and unwavering certainty based on what we know about practice, that folks who spend every waking hour thinking about and learning about some specific skill will tend to display a higher level of competence than those who don't.
Obviously there will be folks who practice incorrectly, and there will be folks who hit a skill ceiling, and there will be a myriad of folks who aren't maximally benefitting from their practice for one reason or another, but if you take a group of people who study and pit them against a group of people who do not study, the group who studies will be more proficient at the given task.
The "10x" effect is real (not a "myth") but it has more to do with skills and exposure than innate talent. (It's also context-specific. I'm a 10x when I get to pick the tools, but a sub-1x on enterprise Java because I just can't bring myself to give a fuck about some Spring/Hibernate/POJO legacy mess.) That's what missed in this conversation. Yes, those mediocre Java programmers (CommodityScrumDrones) really are a drag, but it's not low IQ that has made them what they are, and they're not genetically destined to remain that way. That aspect of a person can change, and quickly.
At any rate, I've met plenty of high-IQ people who are just awful programmers. Smart as hell, but really bad at writing code. I think that attitude is a major factor. If you think programming is important and genuinely want to learn it (and not just "good enough to get a job") then I think it's quite possible for a lot of people to learn how to do it well enough.
Innate talent might matter at the extreme upper end of competitive programming. Just as most people can run a marathon with enough work, but very few will ever get below 3:00, I'd believe that the percentage of people who can reach the top in programming competitions is smaller than the percentage who can program adequately. So there's probably a talent ceiling there, just as there is in athletics. But real programming is more cooperative than competitive and there are plenty of factors (especially design sense and cross-domain knowledge) that matter in the real world more than innate talent.
Programming has a steep learning curve, but what's missed is that a steep learning curve is a good thing. The 10x effect exists because it's possible (especially in the early stages) to improve your own effectiveness by 20, 50, or even 100+ percent per year... and one becomes a true 10x-er not based on in-born talent but by having several 1.5x growth years in a row.
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.