Live data from Hacker News

The programming talent myth

lwn.net

201–210 of 354 posts

Re: The programming talent myth

#201
post #6

> 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 ti…

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.

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.

Re: The programming talent myth

#202
post #58

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…

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.

Re: The programming talent myth

#203
post #162

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…

That would be true if programming were just one thing.

Re: The programming talent myth

#204
post #156
post #125

Earlier quoted context omitted.

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…

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…

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.

Re: The programming talent myth

#205
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?

Re: The programming talent myth

#206
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?

Re: The programming talent myth

#207

Earlier quoted context omitted.

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 t…

>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…

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.

Re: The programming talent myth

#208
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.

[1] http://www.designbyhumans.com/shop/mkronline/

Re: The programming talent myth

#209

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 d…

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 bo…

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.

Post reply on HN