Earlier quoted context omitted.
The findings of this study have been formally retracted by the author. http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hu...
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 programming talent myth
151–160 of 354 posts
Re: The programming talent myth
#152I'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 resp…
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
Re: The programming talent myth
#153Re: The programming talent myth
#154Earlier quoted context omitted.
> 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 wh…
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?
Re: The programming talent myth
#155The 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.
Re: The programming talent myth
#156Earlier quoted context omitted.
>anyone can learn to play piano 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…
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 memor…
>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.
Re: The programming talent myth
#157Earlier quoted context omitted.
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 i…
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.
What I do applaud, is research to into the problem. Which begins, largely, but asking the question.
Re: The programming talent myth
#158http://m.runnersworld.com/sports-psychology/round-number-tim...
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.
Re: The programming talent myth
#159My 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…
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)
Re: The programming talent myth
#160Programming 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 m…
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.